I've currently modified gcc_darwin_amd64.c to allow setting stack size at compilation time:

40a41,45
> #ifdef CGO_STACK_SIZE
>     size = CGO_STACK_SIZE;
>     pthread_attr_setstacksize(&attr, size);
> #endif
>

$ CGO_CFLAGS="-DCGO_STACK_SIZE=0x200000" make

Does it work if you use go build -extldflags=-stack_size=0x200000?

No, I tried that and it still panics:

otool -lV test | grep stack
 stacksize 2097152

The program passes a callback function to the library, the crash is when returning from the go callback:

go -> call c_func (go_cbk)
c   -> call go_cbk
go_cbk returns -> panic

I don't understand why that would be. Do you have a complete test case you can show us that recreates the problem?

Not my exact problem (still trying to isolate it into a sample, cannot make "preparePanic" lock) but one showing setting the stack size does not help (note stack size returned by pthread):

repro.go.txt
repro.h.txt

First attempt: calling Go callback causes a crash

> go build -a -ldflags='-extldflags "-Wl,-stack_size -Wl,0x200000"' repro.go
> otool -lV repro | grep stacksize
 stacksize 2097152
> ./repro                                   
stack size: 524288
no_optimize: 4294705152
fatal: morestack on g0
SIGTRAP: trace trap
PC=0x4052032 m=0 sigcode=1
signal arrived during cgo execution

goroutine 4 [running, locked to thread]:
runtime.abort()
...

Second attempt with no callback showing a clean execution (comment out in repro.h last printf calling goCallback):

> ./repro
stack size: 524288
no_optimize: 4294705152
exit

I'm running into this same issue with my code that calls into cgo that requires a larger stack size. @p8a gcc_darwin_amd64.c workaround was a solution to get it working.

Edit: @ianlancetaylor's suggestion of go build -extldflags=-stack_size=0x200000 did not work either

It would help if somebody could provide a small self-contained test case that demonstrates the problem.

Just to note if someone else runs into it: I thought I needed this because I was getting a weird panic ("fatal: morestack on g0"). Turns out I had a stack overflow in complicated CGo code that was traversing a cyclic tree going back and forth between C and Go with a callback, but I didn't expect it to be cyclic so I ended up with a stack overflow due to endless recursion.

It would help if somebody could provide a small self-contained test case that demonstrates the problem.

@ianlancetaylor my last comment (#28024 (comment)) has a test case

@p8a My apologies. Thanks for sending that. Although I'm surprised to see __cdecl in repro.h, as this issue was reported against Darwin. What does __cdecl mean on Darwin?

So, partially to bump this, because I'm debugging something similar, this can still be reproduced as of Go 1.14.2, and even without __cdecl.

TG has minimal requirement of Go1.5, so better switch to 1.5.4 fir debugging.