[bug #24526] Crash on x86_64 when a program is started with argument that is invalid property list
Follow-up Comment #12, bug #24526 (project gnustep): 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) ___ Additional Item Attachment: File name: foo.diff Size:1 KB ___ 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
[bug #24526] Crash on x86_64 when a program is started with argument that is invalid property list
Follow-up Comment #10, bug #24526 (project gnustep): 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. ___ 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
[bug #24526] Crash on x86_64 when a program is started with argument that is invalid property list
Update of bug #24526 (project gnustep): Open/Closed:Open = Closed ___ Follow-up Comment #11: Ok ... closed. ___ 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
[bug #24526] Crash on x86_64 when a program is started with argument that is invalid property list
Follow-up Comment #9, bug #24526 (project gnustep): 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. ___ 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
[bug #24526] Crash on x86_64 when a program is started with argument that is invalid property list
Follow-up Comment #5, bug #24526 (project gnustep): 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) ___ Additional Item Attachment: File name: backtrace-emacs.txtSize:5 KB File name: backtrace-test-program.txt Size:8 KB ___ 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
[bug #24526] Crash on x86_64 when a program is started with argument that is invalid property list
Follow-up Comment #6, bug #24526 (project gnustep): 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. ___ 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
[bug #24526] Crash on x86_64 when a program is started with argument that is invalid property list
Follow-up Comment #7, bug #24526 (project gnustep): 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. ___ 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
[bug #24526] Crash on x86_64 when a program is started with argument that is invalid property list
Follow-up Comment #8, bug #24526 (project gnustep): 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. ___ 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
[bug #24526] Crash on x86_64 when a program is started with argument that is invalid property list
Follow-up Comment #4, bug #24526 (project gnustep): 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. ___ 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
[bug #24526] Crash on x86_64 when a program is started with argument that is invalid property list
Update of bug #24526 (project gnustep): Status:None = Works For Me ___ Follow-up 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. ___ 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
[bug #24526] Crash on x86_64 when a program is started with argument that is invalid property list
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
[bug #24526] Crash on x86_64 when a program is started with argument that is invalid property list
Follow-up Comment #2, bug #24526 (project gnustep): 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? ___ 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
[bug #24526] Crash on x86_64 when a program is started with argument that is invalid property list
URL: http://savannah.gnu.org/bugs/?24526 Summary: Crash on x86_64 when a program is started with argument that is invalid property list Project: GNUstep Submitted by: yavor Submitted on: Sat Oct 11 00:07:44 2008 Category: Base/Foundation Severity: 3 - Normal Item Group: Bug Status: None Privacy: Public Assigned to: None Open/Closed: Open Discussion Lock: Any ___ Details: 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). ___ File Attachments: --- Date: Sat Oct 11 00:07:44 2008 Name: test.m Size: 2kB By: yavor Test program http://savannah.gnu.org/bugs/download.php?file_id=16649 ___ 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
