In Golang, if you coerce a uintptr variable into unsafe.Pointer (or further, to some *T), the linter will warn with the message "possible miuse of unsafe.Pointer". This makes sense because the uintptr variable may contain an address that points to a piece of invalid memory, and dereferencing such a pointer is catastrophic (usually aborts the program).
I was always aware of the above discipline, but I thought it would be OK to hold the pointers but not dereference them. This is true in C/C++, but not for Golang, which I did not realize until recently.
In fact, the program can panic even if you just keep an invalid pointer on the stack!
The story back from an attempt of interoperation between Golang and JVM, when I was working on a Go-written dynamic library which need to operate bluetooth socket on Android. Android does not provide any native interfaces for bluetooth, so I had to call into JVM and invoke Java APIs.
I have learned JNI 1 beforehand, which is an interface designed for interacting with JVM from native codes. Since JNI is provided to programmers as C++ header files, I had to seek a Golang binding. Then I noticed xlab/android-go which, as utilities, encapsulates the full list of JNI types and functions. The project was out of maintenance for some while, but using only the JNI pieces should be fine.
With the help of xlab/android-go, I quickly finished a prototype of my library, so good, so far. I bundled the library into apk file, ran it on my phone, but unfortunately it crashed with the stack strace
runtime: bad pointer in frame kcore_android/bluetooth.ioWorker.Loop at 0x400018eeb0: 0x1
fatal error: invalid pointer found on stack
runtime stack:
runtime.throw({0x7dbf000df2?, 0x7dbf19b4a0?})
/usr/local/go/src/runtime/panic.go:992 +0x50 fp=0x7d980b6c70 sp=0x7d980b6c40 pc=0x7dbf058ff0
runtime.adjustpointers(0x7d980b7000?, 0x36581?, 0x7dbf164983?, {0x7dbf192338?, 0x7dbf19b4a0?})
/usr/local/go/src/runtime/stack.go:628 +0x1cc fp=0x7d980b6cb0 sp=0x7d980b6c70 pc=0x7dbf0716cc
runtime.adjustframe(0x7d980b7000, 0x7d980b70f8)
/usr/local/go/src/runtime/stack.go:670 +0xa4 fp=0x7d980b6d40 sp=0x7d980b6cb0 pc=0x7dbf0717b4
runtime.gentraceback(0x7d00001000?, 0x7d980b7140?, 0xffffff80ffffffe0?, 0x40001824e0, 0x0, 0x0, 0x7fffffff, 0x7dbf116168, 0x43?, 0x0)
/usr/local/go/src/runtime/traceback.go:330 +0x734 fp=0x7d980b7060 sp=0x7d980b6d40 pc=0x7dbf07b7d4
runtime.copystack(0x40001824e0, 0x1000)
/usr/local/go/src/runtime/stack.go:930 +0x300 fp=0x7d980b7220 sp=0x7d980b7060 pc=0x7dbf071fa0
runtime.newstack()
/usr/local/go/src/runtime/stack.go:1110 +0x37c fp=0x7d980b73d0 sp=0x7d980b7220 pc=0x7dbf0723fc
runtime.morestack()
/usr/local/go/src/runtime/asm_arm64.s:314 +0x70 fp=0x7d980b73d0 sp=0x7d980b73d0 pc=0x7dbf084bc0
goroutine 51 [copystack, locked to thread]:
--- snip ---
I was not frightened, since no code would succeed in one go. But the error report did frustrate me from two perspectives
kcore_android/bluetooth.ioWorker.Loop), but the panic was thrown from some source code that lies out of my codebase (runtime/stack.go).0x1.I guessed the pointer was returned from the Java side, for some unknown reason it had a wierd value of 0x1. But what I didn’t understand is how it could crash my program. I have tried carefully to avoid dereferencing any non-Go pointer in my code.
Also, the mismatch between stack frame and source code made me really difficult to locate the problem. For a time I thought goroutine 51 stopped at the scene where the pointer troubled, as its stack trace contained the aforementioned frame bluetooth.ioWorker.Loop, but it didn’t. In fact, the goroutine stopped at another line when I restarted the program! This was annoying.
It took me almost half a day to resolve and understand the problem. I will first explain the origin of the invalid pointer, and then show how it would crash the program.
0x1 pointerIn JNI, the C type jobject acts as a handle for Java object, which is technically an alias of void*. They can be created by calling most JNI functions like JNIEnv->CallObjectMethod.
Although being a pointer type, a jobject variable is not necessarily a valid pointer. To understand one should know that there exists two kinds of object references in JNI, local reference and global reference. Local references will be recycled at the end of a Java frame, while global references survive longer until you delete them.
They not only differ semantically, but practically diverse in values. Local references often contain smaller values like 0x01, 0x75, yet global references will have values like 0x7dbeffc1cf. I guess local references are not actual pointers but indices of some internal object tables.
Symmetrically, xlab/android-go defines a Jobject which was an alias for unsafe.Pointer. So if you recieve a local reference from JNI functions, you are owning an invalid pointer at Go side.
What’s interesting is that, goroutines do not statically allocate their stack. Instead, they are able to grow or shrink the stack according to our needs. I will not dive into the details of this mechanism, which you may read from the article Go: How does the goroutine stack size evolve? if you are interested.
My panic was thrown by an invalid pointer checking during stack growing. Why should the Go runtime check for invalid pointers here? Because growing a stack involves memory re-allocation, and the runtime must ensure no pointer is invalidated after the potential moving.
To see how a moving could invalidate pointers, let’s consider an example. Say we have a goroutine whose stack ranged in address space 0x8000 - 0x8800. An integer i int was stored at 0x8000, and a pointer ptr *int referenced to that int stored at 0x8004, whose value is 0x8000. Now we grow the stack by moving it to address space 0xA000 - 0xB000. If ptr retains its old value, it will no longer point to i since i has been moved to 0xA000! Therefore, during a stack growth, Go runtime must also check the existence for such pointers, and change their values accordingly.
However, the Go runtime does more than checking whether or not a pointer value falls in the old address space range. It also checks and complains about pointers with small values
func adjustpointers(/*...*/) {
if f.valid() && 0 < p && p < minLegalPointer && debug.invalidptr != 0 {
getg().m.traceback = 2
print("runtime: bad pointer in frame ", funcname(f), " at ", pp, ": ", hex(p), "\n")
throw("invalid pointer found on stack")
}
}
The above snippet can be found at runtime/stack.go. If a pointer value is less than minLegalPointer (which is 4096), the runtime will also panic! And that’s the culprit for my case.
Now I know that the panic comes from two aspects. First I have an invalid pointer due to FFI, although I don’t mean to dereference it. The Go runtime, however, does more than I thought behind the scene. It moves the goroutine stack when necessary, during which it checks and complains for invalid pointers.
This reminds me not to coerce foreign pointer-like values into Go pointers, if you won’t dereference them at the Go side. The safest practice is to keep them uintptr. As a solution, I patch and slim xlab/android-go into hsfzxjy/android-jni-go, which works like a charm.
I also create a minimal example to reproduce the above problem, for whom interested to investigate. In this example, the main goroutine stack will grow during the invocation of foo() -> bar() -> baz(), during which the Go runtime encounters the crafted pointer ptr, and eventually panics.
package main
import (
"fmt"
"unsafe"
)
func main() {
var a [10]int
foo(a)
}
func foo(a [10]int) {
var b [100]int
ptr := unsafe.Pointer(uintptr(1))
bar(b)
fmt.Printf("%p\n", ptr)
}
func bar(a [100]int) {
var b [1000]int
baz(b)
}
func baz(a [1000]int) {}
Author: hsfzxjy.
Link: .
License: CC BY-NC-ND 4.0.
All rights reserved by the author.
Commercial use of this post in any form is NOT permitted.
Non-commercial use of this post should be attributed with this block of text.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。