Comment 1:

Labels changed: added priority-go1, toolbug, cgo, removed priority-triage.

Comment 2:

Status changed to Accepted.

Comment 3 by qeed.quan:

I updated the sdl package to the latest weekly  weekly.2012-02-22 +96bd78e7d35e
the same problem still persists, though I have commented out the executing of a user
defined callback, for now it just executes a goAudioCallback from C which is defined in
the cgo wrapper, rather than a custom one, that still gives me signal 11 though.

Attachments:

1. sdl.tar.gz (7517 bytes)

Comment 4:

Yeah, stumbled across this thing too in my gtk bindings.
Simple test app, that dies with segfault (signal 11 that is):
-----------------------------------------------------------
package main
/*                                                                                      
                 
#include <gtk/gtk.h>                                                              
                       
                                                                                                          
#cgo pkg-config: gtk+-3.0                                                               
                 
*/
import "C"
func main() {
        C.gtk_init(nil, nil)
        C.gtk_file_chooser_button_new(nil, 0)
}
-----------------------------------------------------------
But it happens only with gtk3, same code in C runs just fine. Yes, there is some sort of
threading involved. My machine is linux, x86.

Comment 5:

I cannot reproduce the GTK failure.  It may have been fixed by recent changes
surrounding the main goroutine vs main thread.
I can reproduce the SDL failure at tip, with some changes to make the bindings compile. 
It is caused by the fact that SDL_OpenAudio calls its callback on a new thread, one that
SDL created, and that thread is not set up to call Go code.  A limitation of the current
export mechanism is that the exported functions can only be called on threads that were
created by Go (meaning they called into C using cgo, and that C is invoking the
callback).
I believe there is a trick where you write your callback in C and use pthreads shared
memory to communicate with other C code actually called from a Go thread, and have that
Go thread run the actual Go code you want.  I don't know quite how it works, and I admit
it is not ideal, but we're not going to be able to make major changes to fix this before
Go 1.
I will make the program print a nice message before crashing.

Labels changed: added priority-later, removed priority-go1.

Status changed to LongTerm.

Comment 6:

GTK thing still fails on `go version weekly.2012-03-04 +7a80ccbdc016` (latest tip as of
now). Could be linux/x86 or gtk3 version specific bug. I'll do bisect then, maybe it
gives some hints.

Comment 7:

Did bisect. I had suspicions on that commit and I was right :\
Started to fail after this commit:
11922:daf22f371d51
Russ Cox <rsc@golang.org>
Mon Feb 13 13:52:37 2012 -0500
os/signal: selective signal handling
Should I create another issue about unidentified regression in new os/signal code?

Comment 8:

Yes, please create a separate issue.  Please include information
about the exact Linux distribution and gtk packages you are using.

Comment 9:

Labels changed: added go1.1maybe.

Comment 10:

Status changed to Duplicate.

Merged into issue #4435.