[Bug gdb/31820] New: segfault when target_stack::push > t->stratum ()

[Bug gdb/31820] New: segfault when target_stack::push > t->stratum ()

[jonessyue at qnap dot com]

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.

[Bug gdb/31820] segfault when target_stack::push > t->stratum ()

[tromey at sourceware dot org]

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.

[Bug gdb/31820] segfault when target_stack::push > t->stratum ()

[jonessyue at qnap dot com]

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.

[Bug gdb/31820] segfault when target_stack::push > t->stratum ()

[ssbssa at sourceware dot org]

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.

[Bug gdb/31820] segfault when target_stack::push > t->stratum ()

[jonessyue at qnap dot com]

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.

[Bug gdb/31820] segfault when target_stack::push > t->stratum ()

[tromey at sourceware dot org]

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.