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

Comments

@gopherbot
Copy link

commented Feb 18, 2012

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

This comment has been minimized.

Copy link
Member

commented Feb 21, 2012

Comment 1:

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

@rsc

This comment has been minimized.

Copy link
Contributor

commented Feb 23, 2012

Comment 2:

Status changed to Accepted.

@gopherbot

This comment has been minimized.

Copy link
Author

commented Feb 23, 2012

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link
Contributor

commented Sep 12, 2012

Comment 9:

Labels changed: added go1.1maybe.

@minux

This comment has been minimized.

Copy link
Member

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
5 participants
You can’t perform that action at this time.