bugGNUstep - Bugs: bug #24526, Crash on x86_64 when a program is...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #24526: Crash on x86_64 when a program is started with argument that is invalid property list

Submitted by:  Yavor Doganov <yavor>
Submitted on:  Fri 10 Oct 2008 09:07:44 PM UTC  
 
Category: Base/FoundationSeverity: 3 - Normal
Item Group: BugStatus: Works For Me
Privacy: PublicAssigned to: None
Open/Closed: Closed

(Jump to the original submission Jump to the original submission)

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)

matt rice <ratmice>
Project Member
Fri 26 Dec 2008 06:34:54 AM UTC, comment #11:

Ok ... closed.

Richard Frith-Macdonald <CaS>
Project Member
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.

Yavor Doganov <yavor>
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.

Richard Frith-Macdonald <CaS>
Project Member
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.

Yavor Doganov <yavor>
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.

Yavor Doganov <yavor>
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.

Richard Frith-Macdonald <CaS>
Project Member
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)

Yavor Doganov <yavor>
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.

Yavor Doganov <yavor>
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.

Richard Frith-Macdonald <CaS>
Project Member
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?

Yavor Doganov <yavor>
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.

Richard Frith-Macdonald <CaS>
Project Member
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).

Yavor Doganov <yavor>

 

Attached Files
file #17745:  foo.diff added by ratmice (1KiB - application/octet-stream)
file #16693:  backtrace-emacs.txt added by yavor (6KiB - text/plain)
file #16649:  test.m added by yavor (2KiB - application/octet-stream - Test program)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by ratmice (Updated the item)
  • -unavailable- added by CaS (Posted a comment)
  • -unavailable- added by yavor (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 6 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sat 21 Mar 2009 04:13:03 AM UTCratmiceAttached File-=>Added foo.diff, #17745
    Fri 26 Dec 2008 06:34:54 AM UTCCaSOpen/ClosedOpen=>Closed
    Sat 18 Oct 2008 04:35:28 PM UTCyavorAttached File-=>Added backtrace-emacs.txt, #16693
      Attached File-=>Added backtrace-test-program.txt, #16694
    Wed 15 Oct 2008 10:22:02 AM UTCCaSStatusNone=>Works For Me
    Fri 10 Oct 2008 09:07:44 PM UTCyavorAttached File-=>Added test.m, #16649

    Back to the top


    Powered by Savane 3.1-cleanup1