-
Notifications
You must be signed in to change notification settings - Fork 18k
runtime: OpenReader: Invalid heap pointer in both 1.4rc2 and 1.4rc1 #9191
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Labels
Milestone
Comments
OS X 10.10.1. Cgo is involved. Refinement of the problem in the attached file using standard OpenAL on OS X and the OpenAL go bindings provided provided in the zip. Here is the program from the zip. package main import ( "al" // from https://github.com/gazed/vu/tree/master/src/vu/audio/al "archive/zip" "os" ) // Issue: 9191. All 4 cgo calls and zip.OpenReader are necessary to cause issue. func main() { al.Init() // cgo if dev := al.OpenDevice(""); dev != nil { // cgo if ctx := al.CreateContext(dev, nil); ctx != nil { // cgo defer al.DestroyContext(ctx) // cgo programName := os.Args[0] zip.OpenReader(programName) // crashes? } } } Attachments:
|
I doubt this has anything to do with zip. You would probably get the same crash calling runtime.GC() instead of zip.OpenReader. The problem is that something in the Go heap has a pointer type but contains the value 0x18, which is invalid. I can't recreate the problem on GNU/Linux. I don't see anything in your code that would cause it. This will have to be debugged by somebody with access to a Darwin system. |
Verified that problem can't be recreated on Windows 8.1 using OpenAL.dll from http://kcat.strangesoft.net/openal.html. |
Reproduced on OS X, but it's not a Go problem. the *al.Device returned from al.OpenDevice("") is 0x18, which is obviously an invalid pointer. If al.OpenDevice could return invalid pointers, the value shouldn't use a Go pointer type to store. Because regardless of the platform, the value returned from al.OpenDevice is not a Go pointer (it can be a C pointer, or even an regular integer), so Go's GC won't touch it anyway, you can just use a uintptr to store it. This situation is similar to Window's HANDLE. Arguably, this is a bug of OS X OpenAL implementation, but as ALCdevice is an opaque struct, whether alcOpenDevice returns a real pointer or not doesn't matter that much to a C programmer. For Go's new fully precise GC, not only passing Go heap pointer to C poses problem, even storing a C value (pointer or struct) on Go stack/heap is also potentially problematic as there might be a field that has a pointer type but actually stores an integer. Perhaps we should do something here. Status changed to WorkingAsIntended. |
This issue was closed.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
by pruest:
The text was updated successfully, but these errors were encountered: