public inbox for gdb-prs@sourceware.org
help / color / mirror / Atom feed
* [Bug gdb/31820] New: segfault when target_stack::push > t->stratum ()
@ 2024-05-30 12:22 jonessyue at qnap dot com
2024-05-30 13:36 ` [Bug gdb/31820] " tromey at sourceware dot org
` (4 more replies)
0 siblings, 5 replies; 6+ messages in thread
From: jonessyue at qnap dot com @ 2024-05-30 12:22 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=31820
Bug ID: 31820
Summary: segfault when target_stack::push > t->stratum ()
Product: gdb
Version: 14.1
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: gdb
Assignee: unassigned at sourceware dot org
Reporter: jonessyue at qnap dot com
Target Milestone: ---
cross toolchain: gcc-5.3.1, glibc-2.23, aarch64-linux-gnu-g++
When run gdb-14.2 on aarch64 cross target machine, gdb it self segfault,
like this:
# ./gdb
Segmentation fault (core dumped)
It looks like earlier gdb version works fine, test result:
----------+---------
result | gdb ver
----------+---------
segfault | gdb-14.2
segfault | gdb-10.1
pass | gdb_9.2
pass | gdb-9.1
pass | gdb-8.01
Recompile with '-O0 -g' and check backtrace, 't->stratum ()' triggered
dereference null pointer 0x0 and cause segfault, not sure why the
static variable 'the_dummy_target' with '_vptr.target_ops = 0x0'.
Thread 1 "gdb" received signal SIGSEGV, Segmentation fault.
target_stack::push (this=0xd7cb70, t=0xd04b30 <the_dummy_target>) at
target.c:1206
1206 strata stratum = t->stratum ();
(gdb) bt
#0 target_stack::push (this=0xd7cb70, t=0xd04b30 <the_dummy_target>) at
target.c:1206
#1 0x0000000000666438 in inferior::inferior (this=0xd7c9d0, pid_=<optimized
out>) at inferior.c:90
#2 0x00000000006665d8 in add_inferior_silent (pid=pid@entry=0) at
inferior.c:205
#3 0x0000000000667888 in initialize_inferiors () at inferior.c:1089
#4 0x0000000000805734 in gdb_init () at top.c:2327
#5 0x00000000006c5ee0 in captured_main_1 (context=context@entry=0x3fffffff638)
at main.c:1036
#6 0x00000000006c6c68 in captured_main (data=data@entry=0x3fffffff638) at
main.c:1314
#7 gdb_main (args=args@entry=0x3fffffff658) at main.c:1343
#8 0x000000000041ba24 in main (argc=1, argv=0x3fffffff7a8) at gdb.c:39
(gdb) p t
$1 = (target_ops *) 0xd04b30 <the_dummy_target>
(gdb) p *t
$2 = {
<refcounted_object> = {
m_refcount = 1
},
members of target_ops:
_vptr.target_ops = 0x0
}
(gdb) p the_dummy_target
$3 = {
<target_ops> = {
<refcounted_object> = {
m_refcount = 1
},
members of target_ops:
_vptr.target_ops = 0x0
}, <No data fields>}
(gdb)
Then startover and set a watchpoint on the static variable
'the_dummy_target', it looks like its _vptr.target_ops is 0x0
in the first place (while program loaded?)
(gdb) watch the_dummy_target
Hardware watchpoint 1: the_dummy_target
(gdb) run
<... cut dummy ...>
[New LWP 5506]
[New LWP 5507]
[New LWP 5508]
[New LWP 5510]
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>}
target_stack::push (this=0xd7cb70, t=0xd04b30 <the_dummy_target>) at
target.c:1206
1206 strata stratum = t->stratum ();
(gdb) bt
#0 target_stack::push (this=0xd7cb70, t=0xd04b30 <the_dummy_target>) at
target.c:1206
#1 0x0000000000666438 in inferior::inferior (this=0xd7c9d0, pid_=<optimized
out>) at inferior.c:90
#2 0x00000000006665d8 in add_inferior_silent (pid=pid@entry=0) at
inferior.c:205
#3 0x0000000000667888 in initialize_inferiors () at inferior.c:1089
#4 0x0000000000805734 in gdb_init () at top.c:2327
#5 0x00000000006c5ee0 in captured_main_1 (context=context@entry=0x3fffffff638)
at main.c:1036
#6 0x00000000006c6c68 in captured_main (data=data@entry=0x3fffffff638) at
main.c:1314
#7 gdb_main (args=args@entry=0x3fffffff658) at main.c:1343
#8 0x000000000041ba24 in main (argc=1, argv=0x3fffffff7a8) at gdb.c:39
(gdb)
Since gdb-9.2 works fine so do the same breakpoint to 'target_stack::push',
it shows that _vptr.target_ops is not 0x0 for 't' and 'the_dummy_target'.
Not sure why latest gdb-14.2 is 0x0, will dig further.
(gdb) b target_stack::push
Breakpoint 1 at 0x6cec50: file ../../gdb/target.c, line 560.
(gdb) run
<... cut dummy ...>
Breakpoint 1, target_stack::push (this=this@entry=0xaa05b8 <g_target_stack>,
t=t@entry=0xa272d0 <the_dummy_target>) at ../../gdb/target.c:560
560 {
(gdb) bt
#0 target_stack::push (this=this@entry=0xaa05b8 <g_target_stack>,
t=t@entry=0xa272d0 <the_dummy_target>) at ../../gdb/target.c:560
#1 0x00000000006cff70 in push_target (t=0xa272d0 <the_dummy_target>) at
../../gdb/target.c:579
#2 initialize_targets () at ../../gdb/target.c:3986
#3 0x00000000006dc65c in gdb_init (argv0=<optimized out>) at
../../gdb/top.c:2273
#4 0x00000000005d9428 in captured_main_1 (context=context@entry=0x3fffffff628)
at ../../gdb/main.c:882
#5 0x00000000005da170 in captured_main (data=data@entry=0x3fffffff628) at
../../gdb/main.c:1192
#6 gdb_main (args=args@entry=0x3fffffff648) at ../../gdb/main.c:1217
#7 0x000000000040f3a0 in main (argc=<optimized out>, argv=<optimized out>) at
../../gdb/gdb.c:32
(gdb) l
555
556 /* See target.h. */
557
558 void
559 target_stack::push (target_ops *t)
560 {
561 /* If there's already a target at this stratum, remove it. */
562 strata stratum = t->stratum ();
563
564 if (m_stack[stratum] != NULL)
(gdb) p t
$1 = (target_ops *) 0xa272d0 <the_dummy_target>
(gdb) p *t
$2 = {_vptr.target_ops = 0x8d73e0 <vtable for dummy_target+16>}
(gdb) p the_dummy_target
$3 = {<target_ops> = {_vptr.target_ops = 0x8d73e0 <vtable for
dummy_target+16>}, <No data fields>}
(gdb) p the_dummy_target
$4 = {<target_ops> = {_vptr.target_ops = 0x8d73e0 <vtable for
dummy_target+16>}, <No data fields>}
--
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
@ 2024-05-30 13:36 ` tromey at sourceware dot org
2024-05-31 2:51 ` jonessyue at qnap dot com
` (3 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: tromey at sourceware dot org @ 2024-05-30 13:36 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=31820
Tom Tromey <tromey at sourceware dot org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |tromey at sourceware dot org
--- Comment #1 from Tom Tromey <tromey at sourceware dot org> ---
> _vptr.target_ops = 0x0
Something is pretty wrong with your build.
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.
I doubt this is a gdb bug, but rather something wrong
with your compiler or something along those lines.
--
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
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
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
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: ssbssa at sourceware dot org @ 2024-05-31 11:49 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=31820
Hannes Domani <ssbssa at sourceware dot org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |ssbssa at sourceware dot org
--
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
* [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
` (3 preceding siblings ...)
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: tromey at sourceware dot org @ 2024-06-13 16:16 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=31820
Tom Tromey <tromey at sourceware dot org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |FIXED
Status|UNCONFIRMED |RESOLVED
--- Comment #4 from Tom Tromey <tromey at sourceware dot org> ---
Thanks for the update.
Since this is a compiler issue after all, I'm going to close this bug.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2024-06-13 16:16 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
2024-06-13 6:22 ` jonessyue at qnap dot com
2024-06-13 16:16 ` tromey at sourceware dot org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).