Open matt-42 opened 8 years ago
It's not possible to print an error when this happens since it's not possible to detect (or at least I haven't found a way to do this short of handling SIGSEGV myself, but it might be too late to actually recover from the error). It is possible to make the minimum coroutine stack size a user setting, yes; I'll try to implement this weekend.
As a curiosity, what stack size was sufficient for your use?
I solved my problem with
It fails with 5.
But note that the bug appears only when I compile without the optimization flags. So maybe, you could by default increase the size of the stack size when compiling without optimization. There is a way to do it in GCC and CLANG: http://stackoverflow.com/questions/14618249/is-there-a-builtin-macro-defined-when-optimisation-is-enabled-in-clang
The current value has been chosen empirically, but it's been shown by your example to be a fragile choice -- specially if running user-defined handlers that require a lot of stack space. If that value is increased now, it might fix the issue today for your particular case but might fail in others.
I'm thinking of a better way that's not just a workaround. This might take a while.
@matt-42 I've fixed an issue recently with coroutines that might be related to this bug. Could you please test again?
(The stack was misaligned, and sometimes increasing the stack size helped, but things are stable now even without changes to the stack size.)
It seems like the space allocated for a coroutine is sometime too small. I had really weird bugs caused by the fact that the code of my handler could not fit in this space when compiled without optimizations. Increasing CORO_STACK_MIN solved my problem.
Is it possible to print an error when this append ? and could you let the user increase CORO_STACK_MIN if needed ? Here is the definition of CORO_STACK_MIN: https://github.com/lpereira/lwan/blob/master/common/lwan-coro.c#L35