Follow-up Comment #1, bug #24526 (project gnustep):
Is this simply a case of using an old version of GNUstep?
The bug report mentioned is for a segmentation fault whent he gcc builtin
function to retrieve stack frame info crashes (which it does sometimes) ...
and current/recent gnustep code installs a signal handler to catch such
crashes:
unsigned NSCountFrames(void)
{
jbuf_type *env;
env = jbuf();
if (setjmp(env->buf) == 0)
{
env->segv = signal(SIGSEGV, recover);
env->bus = signal(SIGBUS, recover);
env->addr = 0;
#define _NS_COUNT_HACK(X) if (__builtin_frame_address(X + 1) == 0)
goto done; else env->addr = (void*)(X + 1);
_NS_COUNT_HACK(0); _NS_COUNT_HACK(1); _NS_COUNT_HACK(2);
_NS_COUNT_HACK(3); _NS_COUNT_HACK(4); _NS_COUNT_HACK(5);
_NS_COUNT_HACK(6); _NS_COUNT_HACK(7); _NS_COUNT_HACK(8);
....
done:
signal(SIGSEGV, env->segv);
signal(SIGBUS, env->bus);
}
else
{
env = jbuf();
signal(SIGSEGV, env->segv);
signal(SIGBUS, env->bus);
}
return (unsigned)(uintptr_t)env->addr;
}
So unless I'm missing something, if the code is crashing, either it's an old
version. or the operating system's impelementation of signal() is not
working.
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?24526>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
_______________________________________________
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep
