This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Weird startup issue with -fsplit-stack


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]