On Tue, Jun 10, 2014 at 7:54 AM, Dmitry Antipov <dmanti...@yandex.ru> wrote: > On 05/21/2014 06:10 PM, Ian Lance Taylor wrote: > >> I'm sorry, I have nothing useful to suggest. I agree that that sounds >> like a stack overflow, which should in general be impossible with >> -fsplit-stack when using the gold linker. I don't know what is >> happening here. I've tested with massive recursion so I don't think >> that is the problem by itself. > > > Hm...did you test with a lot of longjmps? I'm just curious about this > comment in libgcc/generic-morestack.c: > > /* The stack segment that we think we are currently using. This will > be correct in normal usage, but will be incorrect if an exception > unwinds into a different stack segment or if longjmp jumps to a > different stack segment. */ > > So, what happens if longjmp jumps to a different segment? Is the result > undefined? Is it possible to detect such a jump?
I have not tested with longjmps. The Go library uses a similar function (setcontext) but it updates the split stack context as it goes. You may be right: a program that splits the stack, then calls setjmp, then splits the stack, then calls longjmp, may mess up after the longjmp when returning from the stack split in the function that calls setjmp. This case can be detected in __generic_releasestack. If the current stack pointer is not in __morestack_current_segment, the code can call __generic_findstack to set __morestack_current_segment to the correct value. Ian
