* [Bug gdb/31820] segfault when target_stack::push > t->stratum ()
2024-05-30 12:22 [Bug gdb/31820] New: segfault when target_stack::push > t->stratum () jonessyue at qnap dot com
2024-05-30 13:36 ` [Bug gdb/31820] " tromey at sourceware dot org
@ 2024-05-31 2:51 ` jonessyue at qnap dot com
2024-05-31 11:49 ` ssbssa at sourceware dot org
` (2 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: jonessyue at qnap dot com @ 2024-05-31 2:51 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=31820
--- Comment #2 from Jones Syue <jonessyue at qnap dot com> ---
(In reply to Tom Tromey from comment #1)
> Something is pretty wrong with your build.
Thank you Tom for kind feedback!
Yes it looks so, in my enviroment only aarch64 target machine has this
issue, perhaps i need to find a more up-to-date aarch64 toolchain and test
again, will get back here later.
Some findings so far:
cross compiling gdb-14.2 for three kinds of toolchain and run gdb
on these target machines, which are aarch64, x86_64, and arm 32bit:
result | target | toolchain | cross prefix
---------+---------+-----------------------+-------------
segfault | aarch64 | gcc-5.3.1, glibc-2.23 | aarch64-linux-gnu-g++
pass | x86_64 | gcc-4.9.2, glibc-2.21 | x86_64-linux-gnu-g++
pass | arm_32 | gcc-4.8.2, glibc-2.17 | arm-linux-gnueabihf-g++
> the_dummy_target is just:
> static dummy_target the_dummy_target;
> The C++ compiler should ensure this is fully initialized
> before use. The vptr should never be null.
Yes iiuc the static variable should be resident in the data section of
binary file after c++ compiled, so use 'readelf' to lookup the gdb binaries
(x86_64, aarch64, and arm_32), it can list both 'the_dummy_target' and
'vtable for dummy_target' address and size.
<x86_64>
# readelf -sW gdb|c++filt |grep -E "vtable for dumm|Num:|^Sym|the_dummy_target"
Symbol table '.dynsym' contains 492 entries:
Num: Value Size Type Bind Vis Ndx Name
Symbol table '.symtab' contains 90386 entries:
Num: Value Size Type Bind Vis Ndx Name
15777: 0000000001333250 16 OBJECT LOCAL DEFAULT 28 the_dummy_target
53793: 0000000000d6c500 1536 OBJECT WEAK DEFAULT 15 vtable for
dummy_target
<aarch64>
# readelf -sW gdb|c++filt |grep -E "vtable for dumm|Num:|^Sym|the_dummy_target"
Symbol table '.dynsym' contains 638 entries:
Num: Value Size Type Bind Vis Ndx Name
Symbol table '.symtab' contains 137653 entries:
Num: Value Size Type Bind Vis Ndx Name
55908: 0000000001244148 16 OBJECT LOCAL DEFAULT 26 the_dummy_target
100396: 0000000000e446c0 1536 OBJECT WEAK DEFAULT 14 vtable for
dummy_target
<arm_32>
# readelf -sW gdb|c++filt |grep -E "vtable for dumm|Num:|^Sym|the_dummy_target"
Symbol table '.dynsym' contains 653 entries:
Num: Value Size Type Bind Vis Ndx Name
Symbol table '.symtab' contains 187343 entries:
Num: Value Size Type Bind Vis Ndx Name
96845: 008d38e8 8 OBJECT LOCAL DEFAULT 26 the_dummy_target
150354: 007928b8 768 OBJECT GLOBAL DEFAULT 15 vtable for dummy_target
Fortunately earlier gdb-7 or gdb-8 still works for my aarch64 target,
so it could run gdb-14.2 and set a breakpoint on 'target_stack::push',
then compare the result of these 3 targets: x86_64, aarch64, and arm_32.
<x86_64>
1. '_vptr.target_ops' is 0xd6c510 not 0x0, looks good.
2. 'info symbol 0xd6c510' vtable for dummy_target + 16 in section .rodata
looks good, 0xd6c510 = 0xd6c500 + 16 is consistent with readelf.
Thread 1 "gdb" hit Breakpoint 1, target_stack::push (this=0x1363180,
t=0x1333250 <the_dummy_target>) at target.c:1204
1204 auto ref = target_ops_ref::new_reference (t);
(gdb) bt
#0 target_stack::push (this=0x1363180, t=0x1333250 <the_dummy_target>) at
target.c:1204
#1 0x000000000079356d in inferior::inferior (this=0x1362fe0, pid_=0) at
inferior.c:90
#2 0x0000000000793b29 in add_inferior_silent (pid=0) at inferior.c:205
#3 0x00000000007966d6 in initialize_inferiors () at inferior.c:1089
#4 0x00000000009e887d in gdb_init () at top.c:2327
#5 0x000000000081e959 in captured_main_1 (context=0x7fffffffe3c0) at
main.c:1036
#6 0x000000000081f651 in captured_main (data=0x7fffffffe3c0) at main.c:1314
#7 0x000000000081f6f3 in gdb_main (args=0x7fffffffe3c0) at main.c:1343
#8 0x0000000000414982 in main (argc=1, argv=0x7fffffffe4c8) at gdb.c:39
(gdb) l
1199 /* We must create a new reference first. It is possible that T is
1200 already pushed on this target stack, in which case we will first
1201 unpush it below, before re-pushing it. If we don't increment the
1202 reference count now, then when we unpush it, we might end up
deleting
1203 T, which is not good. */
1204 auto ref = target_ops_ref::new_reference (t);
1205
1206 strata stratum = t->stratum ();
1207
1208 /* If there's already a target at this stratum, remove it. */
(gdb) p t
$1 = (target_ops *) 0x1333250 <the_dummy_target>
(gdb) p *t
$2 = {<refcounted_object> = {m_refcount = 0}, _vptr.target_ops = 0xd6c510
<vtable for dummy_target+16>}
(gdb) p the_dummy_target
$3 = {<target_ops> = {<refcounted_object> = {m_refcount = 0}, _vptr.target_ops
= 0xd6c510 <vtable for dummy_target+16>}, <No data fields>}
(gdb)
(gdb) info symbol 0x1333250
the_dummy_target in section .data of
/share/CACHEDEV1_DATA/Public/gdb-14.2-O0/gdb
(gdb) info symbol 0xd6c510
vtable for dummy_target + 16 in section .rodata of
/share/CACHEDEV1_DATA/Public/gdb-14.2-O0/gdb
(gdb)
(gdb) info address the_dummy_target
Symbol "the_dummy_target" is static storage at address 0x1333250.
(gdb) info address vtable for dummy_target
Symbol "vtable for dummy_target" is at 0xd6c500 in a file compiled without
debugging.
(gdb)
<aarch64>
1. '_vptr.target_ops' is 0x0, looks bad.
2. 'info address 0x0' looks bad, it is not consistent with readelf output
adress '0xe446c0'.
Thread 1 "gdb" hit Breakpoint 1, target_stack::push (this=0x12bcb80,
t=0x1244148 <the_dummy_target>) at target.c:1204
1204 auto ref = target_ops_ref::new_reference (t);
(gdb) bt
#0 target_stack::push (this=0x12bcb80, t=0x1244148 <the_dummy_target>) at
target.c:1204
#1 0x00000000007bf708 in inferior::inferior (this=0x12bc9e0, pid_=0) at
inferior.c:90
#2 0x00000000007bfc84 in add_inferior_silent (pid=0) at inferior.c:205
#3 0x00000000007c23ac in initialize_inferiors () at inferior.c:1089
#4 0x0000000000a243a0 in gdb_init () at top.c:2327
#5 0x000000000084d2c0 in captured_main_1 (context=0x3fffffff638) at
main.c:1036
#6 0x000000000084e008 in captured_main (data=0x3fffffff638) at main.c:1314
#7 0x000000000084e0a4 in gdb_main (args=0x3fffffff638) at main.c:1343
#8 0x000000000040d868 in main (argc=1, argv=0x3fffffff798) at gdb.c:39
(gdb) l
1199 /* We must create a new reference first. It is possible that T is
1200 already pushed on this target stack, in which case we will first
1201 unpush it below, before re-pushing it. If we don't increment the
1202 reference count now, then when we unpush it, we might end up
deleting
1203 T, which is not good. */
1204 auto ref = target_ops_ref::new_reference (t);
1205
1206 strata stratum = t->stratum ();
1207
1208 /* If there's already a target at this stratum, remove it. */
(gdb)
(gdb) p t
$1 = (target_ops *) 0x1244148 <the_dummy_target>
(gdb) p *t
$2 = {<refcounted_object> = {m_refcount = 0}, _vptr.target_ops = 0x0}
(gdb) p the_dummy_target
$3 = {<target_ops> = {<refcounted_object> = {m_refcount = 0}, _vptr.target_ops
= 0x0}, <No data fields>}
(gdb)
(gdb) info symbol 0x1244148
the_dummy_target in section .data of
/share/CACHEDEV1_DATA/Public/gdb-14.2-O0/gdb
(gdb) info symbol 0x0
No symbol matches 0x0.
(gdb)
(gdb) info address the_dummy_target
Symbol "the_dummy_target" is static storage at address 0x1244148.
(gdb) info address vtable for dummy_target
Symbol "vtable for dummy_target" is at 0xe446c0 in a file compiled without
debugging.
(gdb)
<arm_32>
1. '_vptr.target_ops' is 0x7928c0, looks good.
2. 'info address 0x7928c0' table for dummy_target + 8 in section .rodata
looks good, 0x7928c0 = 0x7928b8 + 16 is consistent with readelf.
Thread 1 "gdb" hit Breakpoint 1, target_stack::push (this=0x9073f4,
t=0x8d38e8 <the_dummy_target>) at target.c:1204
1204 auto ref = target_ops_ref::new_reference (t);
(gdb) bt
#0 target_stack::push (this=0x9073f4, t=0x8d38e8 <the_dummy_target>) at
target.c:1204
#1 0x002cb0c0 in inferior::inferior (this=0x907310, pid_=0) at inferior.c:90
#2 0x002cb4dc in add_inferior_silent (pid=0) at inferior.c:205
#3 0x002cd57c in initialize_inferiors () at inferior.c:1089
#4 0x0049ae88 in gdb_init () at top.c:2327
#5 0x00337fc2 in captured_main_1 (context=0x7dfff7c4) at main.c:1036
#6 0x00338ac6 in captured_main (data=0x7dfff7c4) at main.c:1314
#7 0x00338b2e in gdb_main (args=0x7dfff7c4) at main.c:1343
#8 0x00011ad4 in main (argc=1, argv=0x7dfff924) at gdb.c:39
(gdb) l
1199 /* We must create a new reference first. It is possible that T is
1200 already pushed on this target stack, in which case we will first
1201 unpush it below, before re-pushing it. If we don't increment the
1202 reference count now, then when we unpush it, we might end up
deleting
1203 T, which is not good. */
1204 auto ref = target_ops_ref::new_reference (t);
1205
1206 strata stratum = t->stratum ();
1207
1208 /* If there's already a target at this stratum, remove it. */
(gdb)
(gdb) (gdb) p t
$1 = (target_ops *) 0x8d38e8 <the_dummy_target>
(gdb) p *t
$2 = {<refcounted_object> = {m_refcount = 0}, _vptr.target_ops = 0x7928c0
<vtable for dummy_target+8>}
(gdb) p the_dummy_target
$3 = {<target_ops> = {<refcounted_object> = {m_refcount = 0}, _vptr.target_ops
= 0x7928c0 <vtable for dummy_target+8>}, <No data fields>}
(gdb)
(gdb) info symbol 0x8d38e8
the_dummy_target in section .data of
/share/CACHEDEV1_DATA/Public/gdb-14.2-O0/gdb
(gdb) info symbol 0x7928c0
vtable for dummy_target + 8 in section .rodata of
/share/CACHEDEV1_DATA/Public/gdb-14.2-O0/gdb
(gdb)
(gdb) info address the_dummy_target
Symbol "the_dummy_target" is static storage at address 0x8d38e8.
(gdb) info address vtable for dummy_target
Symbol "vtable for dummy_target" is at 0x7928b8 in a file compiled without
debugging.
(gdb)
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 6+ messages in thread* [Bug gdb/31820] segfault when target_stack::push > t->stratum ()
2024-05-30 12:22 [Bug gdb/31820] New: segfault when target_stack::push > t->stratum () jonessyue at qnap dot com
` (2 preceding siblings ...)
2024-05-31 11:49 ` ssbssa at sourceware dot org
@ 2024-06-13 6:22 ` jonessyue at qnap dot com
2024-06-13 16:16 ` tromey at sourceware dot org
4 siblings, 0 replies; 6+ messages in thread
From: jonessyue at qnap dot com @ 2024-06-13 6:22 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=31820
--- Comment #3 from Jones Syue <jonessyue at qnap dot com> ---
Change gcc version fix this issue for me, per my build it looks like
5.1~5.3 has this issue.
Cross compiling gdb-14.2 and run gdb-14.2 gdb on the same aarch64 target
machine, cross toolchains use the same glibc-2.23, binutils-2.26, and
aarch64-linux-gnu-g++; but different gcc version for bisect:
---------------------+-----------
gdb-14.2 run result | gcc ver
---------------------+-----------
pass | gcc-6.5.0
pass | gcc-5.5.0
pass | gcc-5.4.0
segfault | gcc-5.3.1 (gcc-linaro-5.3-2016.02)
segfault | gcc-5.3.0
segfault | gcc-5.2.0
segfault | gcc-5.1.0
pass | gcc-4.9.4
pass | gcc-4.9.3
Building a new toolchain with various version of gcc/glibc/binutils/...
is an art work, next time will lookup recipes of buildroot, crosstool-ng,
and linuxfromscratch.org, put them into my cookbook to ease the pain :)
Set watchpoint to 'the_dummy_target' and run gdb-14.2 gdb (by old gdb-8),
we could see that _vptr.target_ops is not 0x0 with gcc-5.4.0/4.9.4.
1. pass with gcc-5.4.0:
(gdb) watch the_dummy_target
Hardware watchpoint 1: the_dummy_target
(gdb) run
Starting program: /${MY_PATH}/gcc540-binutils226-glibc223/gdb
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/libthread_db.so.1".
[New Thread 0x3ffb78fedd0 (LWP 21313)]
[New Thread 0x3ffaf0fedd0 (LWP 21314)]
[New Thread 0x3ffb70fedd0 (LWP 21315)]
[New Thread 0x3ffb68fedd0 (LWP 21316)]
Thread 1 "gdb" hit Hardware watchpoint 1: the_dummy_target
Old value = {<target_ops> = {<refcounted_object> = {m_refcount = 0},
_vptr.target_ops = 0xe35ce8 <vtable for dummy_target+16>}, <No data fields>}
New value = {<target_ops> = {<refcounted_object> = {m_refcount = 1},
_vptr.target_ops = 0xe35ce8 <vtable for dummy_target+16>}, <No data fields>}
refcounted_object::incref (this=0x122b558 <the_dummy_target+8>) at
./../gdbsupport/refcounted-object.h:36
36 }
(gdb)
2. segfault with gcc-5.1.0:
(gdb) watch the_dummy_target
Hardware watchpoint 1: the_dummy_target
(gdb) run
Starting program: /${MY_PATH}/gcc510-binutils226-glibc223/gdb
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/libthread_db.so.1".
[New Thread 0x3ffb78fedd0 (LWP 27121)]
[New Thread 0x3ffb70fedd0 (LWP 27122)]
[New Thread 0x3ffb68fedd0 (LWP 27123)]
[New Thread 0x3ffb60fedd0 (LWP 27124)]
Thread 1 "gdb" hit Hardware watchpoint 1: the_dummy_target
Old value = {<target_ops> = {<refcounted_object> = {m_refcount = 0},
_vptr.target_ops = 0x0}, <No data fields>}
New value = {<target_ops> = {<refcounted_object> = {m_refcount = 1},
_vptr.target_ops = 0x0}, <No data fields>}
refcounted_object::incref (this=0x1241298 <the_dummy_target+8>) at
./../gdbsupport/refcounted-object.h:36
36 }
(gdb)
3. pass with gcc-4.9.4:
(gdb) watch the_dummy_target
Hardware watchpoint 1: the_dummy_target
(gdb) run
Starting program: /${MY_PATH}/gcc494-binutils226-glibc223/gdb
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/libthread_db.so.1".
[New Thread 0x3ffb796edd0 (LWP 3806)]
[New Thread 0x3ffb716edd0 (LWP 3807)]
[New Thread 0x3ffb696edd0 (LWP 3808)]
[New Thread 0x3ffb616edd0 (LWP 3809)]
Thread 1 "gdb" hit Hardware watchpoint 1: the_dummy_target
Old value = {<target_ops> = {<refcounted_object> = {m_refcount = 0},
_vptr.target_ops = 0xe1af00 <vtable for dummy_target+16>}, <No data fields>}
New value = {<target_ops> = {<refcounted_object> = {m_refcount = 1},
_vptr.target_ops = 0xe1af00 <vtable for dummy_target+16>}, <No data fields>}
refcounted_object::incref (this=0x1214950 <the_dummy_target+8>) at
./../gdbsupport/refcounted-object.h:36
36 }
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 6+ messages in thread