Bug#274756: libc6: abort() breaks gdb backtraces with 2.6 kernel
On Mon, Oct 04, 2004 at 04:59:08AM +0300, Timo Sirainen wrote:
> On 4.10.2004, at 04:49, Daniel Jacobowitz wrote:
>
> >>>As Daniel wrote, LD_LIBRARY_PATH is not related - just installing
> >>>libc6-dbg on 2.6 kernel machine fixed the problem on my environment.
> >>
> >>It didn't help with me. I have to use LD_LIBRARY_PATH with my own
> >>testing to have useful backtraces.
> >
> >Then please send us a test case.
>
> What do you need? It's a normal Debian unstable with even vanilla 2.6.x
> kernel. I know two other Debian users who have exactly the same
> problem. I don't know if it's a problem with non-Debian users. It's
> been the same ever since I tried 2.6.0. The code doesn't matter, it's
> always the abort() call. It's the same with gcc 2.95 and 3.3.
>
> If it doesn't happen with everyone, could it be AMD vs. Intel issue?
I took the test case from your first URL. I tried to reproduce the
problem.
drow@nevyn:~% mkdir q
drow@nevyn:~% cd q
drow@nevyn:~/q% cat > q.c
int main() { abort(); }
drow@nevyn:~/q% gcc -g -o q q.c
drow@nevyn:~/q% gdb ./q
GNU gdb 6.1-debian
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "i386-linux"...Using host libthread_db
library "/lib/tls/i686/cmov/libthread_db.so.1".
(gdb) run
Starting program: /home/drow/q/q
Program received signal SIGABRT, Aborted.
0xffffe410 in __kernel_vsyscall ()
(gdb) bt
#0 0xffffe410 in __kernel_vsyscall ()
#1 0x4005ce33 in raise () from /lib/tls/i686/cmov/libc.so.6
#2 0x4005e72c in abort () from /lib/tls/i686/cmov/libc.so.6
#3 0x08048399 in main () at q.c:1
You need to work out how this does not happen for you. What version of
GDB you're using, which you've never said. What other confounding
factors, like kernel patches, may be involved.
--
Daniel Jacobowitz
Reply to: