Sat 21 Mar 2009 04:13:03 AM UTC, comment #12:
i was getting this also.......
probably the _builtin_frame_address stuff don't work because something compiled with optimizations and without -fno-omit-frame-pointer....
i personally don't like this backtrace code, people should just use the debugger...
regardless here is a patch for the segfault handlers...
proably needs some autoconfiscation to check if these functions exist..
(file #17745)
|
Fri 26 Dec 2008 06:34:54 AM UTC, comment #11:
Ok ... closed.
|
Thu 25 Dec 2008 09:15:38 PM UTC, comment #10:
Sorry for replying so late.
I can't reproduce with Base 1.18.0 on x86_64-linux-gnu; I even managed to bootstrap Emacs without other errors, which was quite surprising. Please close the bug, thanks.
|
Tue 16 Dec 2008 08:58:31 AM UTC, comment #9:
Is this still a problem?
Given that we can't reproduce it, and the strong possibility that the offending program was just linked with an old version of the library, I'm thinking of closing this bug.
|
Sat 18 Oct 2008 08:25:43 PM UTC, comment #8:
One more thing. Another person could not reproduce this on Debian Etch, amd64, Base version 1.13.0. The test program exited with code 1 and zero when NOHANDLE is defined, as expected.
This (old) version of GNUstep Base does not have the specific code for the handler we're talking about. The default compiler in Etch is GCC 4.1, FWIW.
|
Sat 18 Oct 2008 07:23:13 PM UTC, comment #7:
> but then a gdb backtrace of something different, not of the core > image dumped.
Correct, but in fact it is a crash while executing this preciese command from the make recipe. I can ask him to run gdb on the core, if it helps. It has nothing to do with Lisp stuff -- '(setq make-backup-files nil)' (or whatever) is evaulated as property list which is an invalid array. It seems to me that -[NSUserDefaults __createArgumentDictionary] has a handler for this case, but for some reason it doesn't work.
> so it's not clear whether they demonstrate any bug at all.
I guess you're right, but one thing is clear: both bootstrap-emacs and the test program don't crash on x86, so there should be a bug somewhere.
|
Sat 18 Oct 2008 06:02:05 PM UTC, comment #6:
Unfortunately, neither file shows a backtrace of a crash.
The first file (16693) records a crash and coredump in a make process doing some lisp/emacs stuff ... but then a gdb backtrace of something different, not of the core image dumped.
Both files show gdb backtraces of a running process receiving a signal ... neither shows that the process being debugged would have gone on to crash, so it's not clear whether they demonstrate any bug at all.
Remember, that the sourcecode sample I gave shows that a signal handler has been installed precisely to trap the case where the gcc bug causes a segmentation fault, and recover from it. So a gdb backtrace of the point before the signal handler is called does not demonstrate any problem.
However, it occurs to me that one way our workaround for the gcc bug could be broken is if some other code in another thread changed the signal handler ... there's only a small window in which that could happen, but it's possible I suppose.
|
Sat 18 Oct 2008 04:35:28 PM UTC, comment #5:
A friend who is an official Debian Developer managed to reproduce this on Debian GNU/Linux amd64 (sid), using the debian gnustep-base package (version 1.16.3), installed specifically for this test.
Attached are two files with backtraces -- one with the Emacs CVS (the original problem), and another one with the test program. They are almost identical, and also identical to the ones at the Emacs bug report #1079.
If `signal' is broken on Debian unstable, that's a very grave problem.
(file #16693, file #16694)
|
Thu 16 Oct 2008 05:23:50 PM UTC, comment #4:
Thanks. If the `signal' implementation on that system is broken, I suspect there would be other severe problems in Emacs that would occur before byte-compiling the Emacs Lisp files. We'll investigate.
|
Wed 15 Oct 2008 10:22:02 AM UTC, comment #3:
Correct ... it's not reproducible on my x86_64 debian system... if the code really crashed when raising an exception on a normal system, I'd know about it.
Could your bug reporter have software linked to an old version?
The other alternative would seem to be a problem with the signal() function, but this should never fail unless we supply an invalid argument (would require the base library to be built with a bad header so that the SIGSEGV constant is mis-defined), or if we are somehow linked with a library which overrides signal() to replace the standard version with a broken one.
|
Wed 15 Oct 2008 05:45:59 AM UTC, comment #2:
It was reproduced by the original bug reporter with gnustep-startup-0.20, but I also asked him to try with Base SVN trunk -- same result.
I assume that you cannot reproduce on x86_64, right?
|
Wed 15 Oct 2008 05:17:49 AM UTC, comment #1:
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.
|
Fri 10 Oct 2008 09:07:44 PM UTC, original submission:
This was reported at http://emacsbugs.donarmstrong.com/1079 as a bug in the GNUstep port of Emacs.
Using the attached test program, on x86:
$ ./test --eval '(setq foo 1)'
Useless info about bundle: <NSBundle: 0x813ec98> </usr/bin/Resources/test>
'--eval' - a string.
'(setq foo 1)' failed with:
Parse failed - Parse failed at line 1 (char 7) - unexpected character (wanted ',' or ')').
Failure.
$ echo $?
1
$ NOHANDLE=yes ./test --eval '(setq foo 1)'
Useless info about bundle: <NSBundle: 0x813ed18> </usr/bin/Resources/test>
NOHANDLE defined; should exit with success.
$ echo $?
0
On x86_64, however, it crashes with a backtrace analogical to that when bootstrapping Emacs (http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=1079#45).
|