You could also try adding os.Flush() to recover see if it will prints out something useful then
On Wednesday, 3 October 2018 16:57:33 UTC+2, papost...@gmail.com wrote: > > 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.
