Thanks, I'll take a look at it. "recover" unfortunately does not help because control never gets back to the go side and this is the most difficult part - not knowing what the panic actually is.
My current "workaround" is to timeout the cgo call in my code but I'm obviously leaking goroutines. - Paul On Wednesday, October 3, 2018 at 7:48:18 AM UTC-4, Scott Cotton wrote: > > Also, potentially of interest is [a different callback mechanism]( > http://godoc.org/zikichombo.org/sio/libsio#Cb) which bypasses > c->Go callbacks on a foreign thread with a different mechanism that > doesn't have deal with coordinating signal handling switches between Go and > C. > > It is in alpha, though, and if you try it you will likely need the latest > PR which isn't yet merged. > > Scott > > On Wednesday, 3 October 2018 10:07:22 UTC+2, Scott Cotton wrote: >> >> don't know if it's related, but maybe adding below to your callback (from >> portaudio callback) will shed some light on your problem >> >> >> >> >> defer func() { >> // Don't let PortAudio silently swallow panics. >> if x := recover(); x != nil { >> buf := make([]byte, 1<<10) >> for runtime.Stack(buf, true) == len(buf) { >> buf = make([]byte, 2*len(buf)) >> } >> fmt.Fprintf(os.Stderr, "panic in portaudio stream callback: %s\n\n%s", >> x, buf) >> os.Exit(2) >> } >> }() >> On Tuesday, 2 October 2018 02:00:36 UTC+2, Ian Lance Taylor wrote: >>> >>> On Mon, Oct 1, 2018 at 4:52 PM, pba <papost...@gmail.com> wrote: >>> > >>> > I'm running into a situation where my program deadlocks due to >>> (apparently) >>> > a call to runtime.(*sigctxt).preparePanic which never exits (stack >>> below). >>> > >>> > The program uses cgo and passes callbacks to the C library, this >>> particular >>> > panic seems to be triggered when the go callback returns to the C >>> code. I >>> > cannot debug the C code (binary dependency). >>> > >>> > Any suggestions on how to make the the program crash cleanly (i.e. >>> panic and >>> > exit) ? >>> > >>> > go version go1.11 darwin/amd64 >>> > macOS Sierra (10.12.6) >>> > >>> > 2359 Thread_1644947 >>> > + 2359 _sigtramp (in libsystem_platform.dylib) + 26 >>> [0x7fff9656cb3a] >>> > + 2359 runtime.sigtramp (in test) + 51 [0x4065fe3] >>> > + 2359 runtime.sigtrampgo (in test) + 544 [0x4049000] >>> > + 2359 runtime.sighandler (in test) + 1788 [0x404866c] >>> > + 2359 runtime.(*sigctxt).preparePanic (in test) + 172 >>> > [0x40475fc] >>> >>> preparePanic is only called if your program has already gotten a >>> signal. In this case it looks like preparePanic is itself causing a >>> signal. There is some special code in Darwin that fires when a >>> program does a division by zero or otherwise gets a SIGFPE signal; is >>> it possible that this is happening in your program? >>> >>> Ian >>> >> -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
