runtime: Go 1.5 runtime panic, GC related

[fogleman]

Today I was playing with go-cairo, gl and glfw and stumbled on an issue. I suspect the GC is involved. Runs fine with Go 1.4.2.

Here is the failing code:

https://gist.github.com/fogleman/568248e76b015efe801a

Note that calling runtime.GC() each iteration causes it to run a little longer, but it still crashes the same way.

I'm grabbing a buffer from a cairo.Surface and copying it into an OpenGL texture. Here's the code from go-cairo that gives me the bytes:

https://github.com/ungerik/go-cairo/blob/master/surface.go#L611-L620

Something about surface.GetData() is causing trouble. I don't have to actually pass it into gl.TexImage2D. In that case it crashes at gl.Begin instead.

Here is the panic output:

fatal error: unexpected signal during runtime execution
[signal 0xb code=0x1 addr=0x0 pc=0x7fff8ac7744b]

runtime stack:
runtime.throw(0x42d2b20, 0x2a)
    /usr/local/Cellar/go/1.5/libexec/src/runtime/panic.go:527 +0x90
runtime.sigpanic()
    /usr/local/Cellar/go/1.5/libexec/src/runtime/sigpanic_unix.go:12 +0x5a

goroutine 1 [syscall, locked to thread]:
runtime.cgocall(0x4014620, 0xc82003fd98, 0x0)
    /usr/local/Cellar/go/1.5/libexec/src/runtime/cgocall.go:120 +0x11b fp=0xc82003fd48 sp=0xc82003fd18
github.com/go-gl/gl/v2.1/gl._Cfunc_glowTexImage2D(0x7fff8ac77420, 0xde1, 0x28000001908, 0x1e0, 0x140100001908, 0xc82007e000)
    github.com/go-gl/gl/v2.1/gl/_obj/_cgo_gotypes.go:36312 +0x35 fp=0xc82003fd98 sp=0xc82003fd48
github.com/go-gl/gl/v2.1/gl.TexImage2D(0xde1, 0x28000001908, 0x1e0, 0x140100001908, 0xc82007e000)
    /Users/fogleman/go/src/github.com/go-gl/gl/v2.1/gl/package.go:24772 +0x6d fp=0xc82003fdd0 sp=0xc82003fd98
main.setTexture(0xc82006a040)
    /Users/fogleman/go/src/github.com/fogleman/go-draw/main.go:30 +0x104 fp=0xc82003fe28 sp=0xc82003fdd0
main.main()
    /Users/fogleman/go/src/github.com/fogleman/go-draw/main.go:83 +0x686 fp=0xc82003ff60 sp=0xc82003fe28
runtime.main()
    /usr/local/Cellar/go/1.5/libexec/src/runtime/proc.go:111 +0x2b0 fp=0xc82003ffb0 sp=0xc82003ff60
runtime.goexit()
    /usr/local/Cellar/go/1.5/libexec/src/runtime/asm_amd64.s:1696 +0x1 fp=0xc82003ffb8 sp=0xc82003ffb0

goroutine 17 [syscall, locked to thread]:
runtime.goexit()
    /usr/local/Cellar/go/1.5/libexec/src/runtime/asm_amd64.s:1696 +0x1
exit status 2

[ianlancetaylor]

CC @RLH @aclements

It looks like C code is dereferencing a NULL pointer.

[aclements]

@fogleman, I agree with @ianlancetaylor's diagnosis. Based on the crashing program counter, it looks like this is a NULL pointer dereference in a C library, which probably indicates a bug in one of the wrapper packages you're using (I would guess go-cairo based on what you said about surface.GetData()). Unfortunately, I wasn't able to reproduce it locally. If you run your program under gdb, it should trap at the NULL pointer dereference. If you then use the backtrace command, it may give us a better idea of where the crash is actually happening and what's causing it. You might have to install some symbol packages to get a full backtrace from gdb.

[fogleman]

@aclements, I ran it in gdb and here's what I got:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x1803 of process 747]
0x00007fff8a33d622 in ?? () from /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib
(gdb) bt
#0  0x00007fff8a33d622 in ?? () from /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib
#1  0x0000000000000000 in ?? ()
(gdb) 

Would the symbol packages you mentioned help here? Where do I get them?

Like I mentioned, this works fine in Go 1.4.2.

[thaustad]

This is likely caused by the new GOMAXPROCS default. GL functions must be called from the same OS-thread that called MakeContextCurrent. At some point your code is probably running under a different OS-thread without the GL context. Try importing runtime and add this to your code:

func init() {
    runtime.LockOSThread()
}

Also note that most of the glfw functions must be called from the main thread.

[fogleman]

@thaustad, doh! You're right. I forgot about the GOMAXPROCS change. LockOSThread did indeed fix my issue.

[aclements]

Nice call, @thaustad! @fogleman, handling this automatically would be a good feature request to send to go-gl. I see their readme does mention LockOSThread, but I bet this it going to start biting a lot more people. The x/mobile GL bindings handle this by forwarding all of the GL calls to one locked thread so users don't have to worry about goroutines versus OS threads.