Public bug reported:
To help in the development of apport we're using the chaos-marmosets set
of binaries, which triggers various crashes. In particular, we're using
/usr/bin/divide-by-zero which does as its name indicates, which
naturally triggers a native crash.
However, GDB fails on s390x. Note that for the following I have the
debugging symbols from ddebs.ubuntu.com installed:
ubuntu@glibc-proposed:/tmp$ gdb /usr/bin/divide-by-zero
[snip]
Reading symbols from /usr/bin/divide-by-zero...
Reading symbols from
/usr/lib/debug/.build-id/14/82d2d64c3383ca479f17bfd17b314295c99f13.debug...
(gdb) run
Starting program: /usr/bin/divide-by-zero
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/s390x-linux-gnu/libthread_db.so.1".
Program received signal SIGTRAP, Trace/breakpoint trap.
0x000002aa00000814 in ?? ()
(gdb) bt
#0 0x000002aa00000814 in ?? ()
#1 0x000003fff7d2baac in __libc_start_call_main (main=0x2aa00000690 <main>,
main@entry=<error reading variable: value has been optimized out>,
argc=argc@entry=1, argv=argv@entry=0x3ffffffa468)
at ../sysdeps/nptl/libc_start_call_main.h:58
#2 0x000003fff7d2bbae in __libc_start_main_impl (main=<optimized out>, argc=1,
argv=0x3ffffffa468, init=<optimized out>, fini=<optimized out>,
rtld_fini=0x3fff7f85650 <_dl_fini>,
stack_end=0x3ffffffa3b0) at ../csu/libc-start.c:360
#3 0x000002aa00000720 in _start ()
(gdb) info address divide_by_zero
Symbol "divide_by_zero" is a function at address 0x2aa00000810.
(gdb)
So at this point GDB isn't capable of identifying the various symbols on
the stack, which isn't ideal.
Now, if I try to step in:
ubuntu@glibc-proposed:/tmp$ gdb -q /usr/bin/divide-by-zero
Reading symbols from /usr/bin/divide-by-zero...
Reading symbols from
/usr/lib/debug/.build-id/14/82d2d64c3383ca479f17bfd17b314295c99f13.debug...
(gdb) start
Temporary breakpoint 1 at 0x690: file divide-by-zero.c, line 29.
Starting program: /usr/bin/divide-by-zero
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/s390x-linux-gnu/libthread_db.so.1".
Temporary breakpoint 1, main (argc=1, argv=0x3ffffffa468) at divide-by-zero.c:29
warning: 29 divide-by-zero.c: No such file or directory
(gdb) s
34 in divide-by-zero.c
(gdb)
divide_by_zero () at divide-by-zero.c:25
25 in divide-by-zero.c
(gdb)
/build/gdb-nviNEX/gdb-15.1/gdb/infrun.c:2982: internal-error: resume_1:
Assertion `pc_in_thread_step_range (pc, tp)' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
----- Backtrace -----
0x2aa100a247f ???
0x2aa104efce5 ???
0x2aa104eff7f ???
0x2aa10668c13 ???
0x2aa102553db ???
0x2aa10255bd1 ???
0x2aa10255f5f ???
0x2aa10259195 ???
0x2aa1025c315 ???
0x2aa1025e9a5 ???
0x2aa10260015 ???
0x2aa1066951b ???
0x2aa10669e6d ???
0x2aa102b01cd ???
0x2aa102b3607 ???
0x2aa0ffed839 ???
0x3ffb142baab __libc_start_call_main
../sysdeps/nptl/libc_start_call_main.h:58
0x3ffb142bbad __libc_start_main_impl
../csu/libc-start.c:360
0x2aa0fff8f8f ???
0xffffffffffffffff ???
---------------------
/build/gdb-nviNEX/gdb-15.1/gdb/infrun.c:2982: internal-error: resume_1:
Assertion `pc_in_thread_step_range (pc, tp)' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n)
I can provide a core dump if you think that'd help, but it seems
trivially reproducible.
** Affects: gdb (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to gdb in Ubuntu.
https://bugs.launchpad.net/bugs/2075204
Title:
gdb on s390x chokes on divide-by-zero from chaos-marmosets
Status in gdb package in Ubuntu:
New
Bug description:
To help in the development of apport we're using the chaos-marmosets
set of binaries, which triggers various crashes. In particular, we're
using /usr/bin/divide-by-zero which does as its name indicates, which
naturally triggers a native crash.
However, GDB fails on s390x. Note that for the following I have the
debugging symbols from ddebs.ubuntu.com installed:
ubuntu@glibc-proposed:/tmp$ gdb /usr/bin/divide-by-zero
[snip]
Reading symbols from /usr/bin/divide-by-zero...
Reading symbols from
/usr/lib/debug/.build-id/14/82d2d64c3383ca479f17bfd17b314295c99f13.debug...
(gdb) run
Starting program: /usr/bin/divide-by-zero
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/s390x-linux-gnu/libthread_db.so.1".
Program received signal SIGTRAP, Trace/breakpoint trap.
0x000002aa00000814 in ?? ()
(gdb) bt
#0 0x000002aa00000814 in ?? ()
#1 0x000003fff7d2baac in __libc_start_call_main (main=0x2aa00000690 <main>,
main@entry=<error reading variable: value has been optimized out>,
argc=argc@entry=1, argv=argv@entry=0x3ffffffa468)
at ../sysdeps/nptl/libc_start_call_main.h:58
#2 0x000003fff7d2bbae in __libc_start_main_impl (main=<optimized out>,
argc=1, argv=0x3ffffffa468, init=<optimized out>, fini=<optimized out>,
rtld_fini=0x3fff7f85650 <_dl_fini>,
stack_end=0x3ffffffa3b0) at ../csu/libc-start.c:360
#3 0x000002aa00000720 in _start ()
(gdb) info address divide_by_zero
Symbol "divide_by_zero" is a function at address 0x2aa00000810.
(gdb)
So at this point GDB isn't capable of identifying the various symbols
on the stack, which isn't ideal.
Now, if I try to step in:
ubuntu@glibc-proposed:/tmp$ gdb -q /usr/bin/divide-by-zero
Reading symbols from /usr/bin/divide-by-zero...
Reading symbols from
/usr/lib/debug/.build-id/14/82d2d64c3383ca479f17bfd17b314295c99f13.debug...
(gdb) start
Temporary breakpoint 1 at 0x690: file divide-by-zero.c, line 29.
Starting program: /usr/bin/divide-by-zero
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/s390x-linux-gnu/libthread_db.so.1".
Temporary breakpoint 1, main (argc=1, argv=0x3ffffffa468) at
divide-by-zero.c:29
warning: 29 divide-by-zero.c: No such file or directory
(gdb) s
34 in divide-by-zero.c
(gdb)
divide_by_zero () at divide-by-zero.c:25
25 in divide-by-zero.c
(gdb)
/build/gdb-nviNEX/gdb-15.1/gdb/infrun.c:2982: internal-error: resume_1:
Assertion `pc_in_thread_step_range (pc, tp)' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
----- Backtrace -----
0x2aa100a247f ???
0x2aa104efce5 ???
0x2aa104eff7f ???
0x2aa10668c13 ???
0x2aa102553db ???
0x2aa10255bd1 ???
0x2aa10255f5f ???
0x2aa10259195 ???
0x2aa1025c315 ???
0x2aa1025e9a5 ???
0x2aa10260015 ???
0x2aa1066951b ???
0x2aa10669e6d ???
0x2aa102b01cd ???
0x2aa102b3607 ???
0x2aa0ffed839 ???
0x3ffb142baab __libc_start_call_main
../sysdeps/nptl/libc_start_call_main.h:58
0x3ffb142bbad __libc_start_main_impl
../csu/libc-start.c:360
0x2aa0fff8f8f ???
0xffffffffffffffff ???
---------------------
/build/gdb-nviNEX/gdb-15.1/gdb/infrun.c:2982: internal-error: resume_1:
Assertion `pc_in_thread_step_range (pc, tp)' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n)
I can provide a core dump if you think that'd help, but it seems
trivially reproducible.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/2075204/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
