On 05/20/2014 10:16 PM, Ian Lance Taylor wrote:
This is the call to __morestack_block_signals in morestack.S. It
should only be possible if __morestack_block_signals or something it
calls directly has a split stack. __morestack_block_signals has the
no_split_stack attribute, meaning that it should never call
__morestack. __morestack_block_signals only calls pthread_sigmark or
sigprocmask, neither of which should be compiled with -fsplit-stack.
So something has gone wrong, but I don't know what.
Thanks - that was an application's own copy of pthread_sigmask (compiled
with -fsplit-stack) linked into the binary due to a subtle configuration
issue.
The next major problem is that -fsplit-stack code randomly crashes with the
useless gdb backtrace, usually pointing to the very beginning of the function
(plus occasional "Cannot access memory at..." messages), e.g.:
(gdb) bt 1
#0 0x00000000005a615b in mark_object (arg=0) at ../../trunk/src/alloc.c:6039
6037 void
6038 mark_object (Lisp_Object arg)
==> 6039 {
IIUC this usually (with traditional stack) happens due to stack overflow.
But what may be the case with -fsplit-stack? I do not receive any error
messages from libgcc, and there are a lot of free heap memory. If that matters,
mark_object is recursive, and recursion depth may be very high, up to a few
tens of thousands calls.
Dmitry
