Panic was caused by a stack smash, default cgo thread stack size was too
small. My fix is to change cgo thread stack size at compile time by
patching gcc_darwin_amd64.c, _cgo_sys_thread_start:
40a41,45
> #ifdef CGO_STACK_SIZE
> size = CGO_STACK_SIZE;
> pthread_attr_setstacksize(&attr, si
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.
Answering my own question: using -extflags and passing the appropriate
clang options (-stack_size)
("go tool link" for all options).
On Monday, October 1, 2018 at 3:24:11 PM UTC-4, papost...@gmail.com wrote:
>
> I'm using cgo to interop with a 3rd-party library which requires at least
> 3MB o
GOARCH="amd64"
GOOS="darwin"
- Paul
On Monday, October 1, 2018 at 3:32:06 PM UTC-4, Ian Lance Taylor wrote:
>
> On Mon, Oct 1, 2018 at 12:21 PM, >
> wrote:
> >
> > I'm using cgo to interop with a 3rd-party library which requires at
> least
> > 3MB of stack size - what is the proper way of
I'm using cgo to interop with a 3rd-party library which requires at least
3MB of stack size - what is the proper way of initializing code to support
that ? All my cgo calls are done from separate goroutines which use
channels for in/out.
Thanks.
--
You received this message because you are s
