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

Group
 
 

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

Submitter:  Yavor Doganov <yavor>
Submitted:  Fri 10 Oct 2008 09:07:44 PM UTC
   
 
Category:  Base/Foundation Severity:  3 - Normal
Item Group:  Bug Status:  Works For Me
Privacy:  Public Assigned to:  None
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

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>
Group Member
Fri 26 Dec 2008 06:34:54 AM UTC, comment #11: 

Ok ... closed.

Richard Frith-Macdonald <CaS>
Group 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>
Group 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>
Group 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>
Group 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>
Group 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>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

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
  • -email is unavailable- added by ratmice (Updated the item)
  • -email is unavailable- added by CaS (Posted a comment)
  • -email is unavailable- added by yavor (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2009-03-21 ratmice Attached File- Added foo.diff, #17745
    2008-12-26 CaS Open/ClosedOpen Closed
    2008-10-18 yavor Attached File- Added backtrace-emacs.txt, #16693
        Attached File- Added backtrace-test-program.txt, #16694
    2008-10-15 CaS StatusNone Works For Me
    2008-10-10 yavor Attached File- Added test.m, #16649

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code