Skip to content
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

cmd/cgo: cannot run callback on non-Go thread #3068

Closed
gopherbot opened this issue Feb 18, 2012 · 10 comments
Closed

cmd/cgo: cannot run callback on non-Go thread #3068

gopherbot opened this issue Feb 18, 2012 · 10 comments
Milestone

Comments

@gopherbot
Copy link

by qeed.quan:

Before filing a bug, please check whether it has been fixed since
the latest release: run "hg pull", "hg update default", rebuild, and
retry
what you did to
reproduce the problem.  Thanks.

What steps will reproduce the problem?
1. run test.go with the sdl bindings i attached, sdl version i used is 1.2.14

What is the expected output?
should print "test" periodically if all works ok.

What do you see instead?

Which compiler are you using (5g, 6g, 8g, gccgo)?
6g

Which operating system are you using?
Slackware Linux 64 bit version

Which revision are you using?  (hg identify)
43cf9b39b647 weekly/weekly.2012-02-14
using go amd64


Please provide any additional information below.

I think this is a threading problem, since using pthreads also leads to segfault. when I
try to do stuff like pthread_join on a c thread that calls a go function.

I've attached my SDL bindings for SDL 1.2.14 and 
a sample go code that receives signal 11

Attachments:

  1. sdl.tar.gz (7419 bytes)
  2. test.go (406 bytes)
@dsymonds
Copy link
Contributor

Comment 1:

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

@rsc
Copy link
Contributor

rsc commented Feb 23, 2012

Comment 2:

Status changed to Accepted.

@gopherbot
Copy link
Author

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)

@nsf
Copy link

nsf commented Mar 2, 2012

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.

@rsc
Copy link
Contributor

rsc commented Mar 8, 2012

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.

@nsf
Copy link

nsf commented Mar 8, 2012

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.

@nsf
Copy link

nsf commented Mar 8, 2012

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?

@rsc
Copy link
Contributor

rsc commented Mar 8, 2012

Comment 8:

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

@rsc
Copy link
Contributor

rsc commented Sep 12, 2012

Comment 9:

Labels changed: added go1.1maybe.

@minux
Copy link
Member

minux commented Jan 27, 2013

Comment 10:

Status changed to Duplicate.

Merged into issue #4435.

@rsc rsc added this to the Go1.1 milestone Apr 14, 2015
@rsc rsc removed the go1.1maybe label Apr 14, 2015
@golang golang locked and limited conversation to collaborators Jun 24, 2016
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

5 participants