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
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.
Update of bug #24526 (project gnustep):
Open/Closed:Open = Closed
___
Follow-up Comment #11:
Ok ... closed.
___
Reply to this
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.
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
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.
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
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
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.
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
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
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?
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
13 matches
Mail list logo
