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.
