[Bug varobj/28131] New: Segfault in gdbpy_enter_varobj::gdbpy_enter_varobj when debugging in VS Code

[Bug varobj/28131] New: Segfault in gdbpy_enter_varobj::gdbpy_enter_varobj when debugging in VS Code

[usaonmonday at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=28131

            Bug ID: 28131
           Summary: Segfault in gdbpy_enter_varobj::gdbpy_enter_varobj
                    when debugging in VS Code
           Product: gdb
           Version: HEAD
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: varobj
          Assignee: unassigned at sourceware dot org
          Reporter: usaonmonday at gmail dot com
  Target Milestone: ---

Anything I debug in VS Code ends up in gdb exiting on segfault, if I try
stepping through the code.

I compiled a debug version of gdb and got a core dump. Here is the backtrace:
#0  0x00007fca50787d22 in raise () from /usr/lib/libc.so.6
#1  0x00007fca50771862 in abort () from /usr/lib/libc.so.6
#2  0x000000000069a943 in handle_sigsegv (sig=11) at
../../binutils-gdb/gdb/event-top.c:893
#3  <signal handler called>
#4  gdbpy_enter_varobj::gdbpy_enter_varobj (this=0x7fffaef03e00, var=0x63f00b0)
at ../../binutils-gdb/gdb/varobj.c:209
#5  0x00000000008a3687 in py_varobj_iter::~py_varobj_iter (this=0x64cb140,
__in_chrg=<optimized out>) at ../../binutils-gdb/gdb/python/py-varobj.c:51
#6  0x00000000008a36ca in py_varobj_iter::~py_varobj_iter (this=0x64cb140,
__in_chrg=<optimized out>) at ../../binutils-gdb/gdb/python/py-varobj.c:53
#7  0x0000000000a7f7c8 in std::default_delete<varobj_iter>::operator()
(this=0x6839078, __ptr=0x64cb140)
    at /home/user/gcc-env/include/c++/11/bits/unique_ptr.h:85
#8  0x0000000000a7ea84 in std::unique_ptr<varobj_iter,
std::default_delete<varobj_iter> >::~unique_ptr (this=0x6839078,
__in_chrg=<optimized out>)
    at /home/user/gcc-env/include/c++/11/bits/unique_ptr.h:361
#9  0x0000000000a7e7b0 in varobj_dynamic::~varobj_dynamic (this=0x6839060,
__in_chrg=<optimized out>) at ../../binutils-gdb/gdb/varobj.c:108
#10 0x0000000000a7d00b in varobj::~varobj (this=0x63f00b0, __in_chrg=<optimized
out>) at ../../binutils-gdb/gdb/varobj.c:1850
#11 0x0000000000a7c91c in delete_variable_1 (delcountp=0x7fffaef03fec,
var=0x63f00b0, only_children_p=false, remove_from_parent_p=true)
    at ../../binutils-gdb/gdb/varobj.c:1729
#12 0x0000000000a7c7a3 in delete_variable (var=0x63f00b0,
only_children_p=false) at ../../binutils-gdb/gdb/varobj.c:1678
#13 0x0000000000a79a9e in varobj_delete (var=0x63f00b0, only_children=false) at
../../binutils-gdb/gdb/varobj.c:449
#14 0x00000000007e84b5 in mi_cmd_var_delete (command=0x6675d50 "var-delete",
argv=0x6640520, argc=1) at ../../binutils-gdb/gdb/mi/mi-cmd-var.c:182
#15 0x000000000080319a in mi_cmd_execute (parse=0x63eb4d0) at
../../binutils-gdb/gdb/mi/mi-main.c:2083
#16 0x0000000000802664 in captured_mi_execute_command (uiout=0x25c8eb0,
context=0x63eb4d0) at ../../binutils-gdb/gdb/mi/mi-main.c:1794
#17 0x0000000000802c3c in mi_execute_command (cmd=0x65c7200 "1221-var-delete
var76", from_tty=1) at ../../binutils-gdb/gdb/mi/mi-main.c:1953
#18 0x00000000007ebd76 in mi_execute_command_wrapper (cmd=0x65c7200
"1221-var-delete var76") at ../../binutils-gdb/gdb/mi/mi-interp.c:275
#19 0x00000000007ebdff in mi_execute_command_input_handler (cmd=...) at
../../binutils-gdb/gdb/mi/mi-interp.c:304
#20 0x000000000069a88c in gdb_readline_no_editing_callback
(client_data=0x242eb70) at ../../binutils-gdb/gdb/event-top.c:848
#21 0x000000000069a10d in stdin_event_handler (error=0, client_data=0x242eb70)
at ../../binutils-gdb/gdb/event-top.c:515
#22 0x0000000000bde882 in handle_file_event (file_ptr=0x25a2580, ready_mask=1)
at ../../binutils-gdb/gdbsupport/event-loop.cc:575
#23 0x0000000000bdee1d in gdb_wait_for_event (block=1) at
../../binutils-gdb/gdbsupport/event-loop.cc:701
#24 0x0000000000bddddb in gdb_do_one_event () at
../../binutils-gdb/gdbsupport/event-loop.cc:237
#25 0x00000000007c3745 in start_event_loop () at
../../binutils-gdb/gdb/main.c:421
#26 0x00000000007c3864 in captured_command_loop () at
../../binutils-gdb/gdb/main.c:481
#27 0x00000000007c50e3 in captured_main (data=0x7fffaef04520) at
../../binutils-gdb/gdb/main.c:1353
#28 0x00000000007c5149 in gdb_main (args=0x7fffaef04520) at
../../binutils-gdb/gdb/main.c:1368
#29 0x00000000004188bd in main (argc=3, argv=0x7fffaef04638) at
../../binutils-gdb/gdb/gdb.c:32

It seems like here
gdbpy_enter_varobj::gdbpy_enter_varobj (const struct varobj *var)
: gdbpy_enter (var->root->exp->gdbarch, var->root->exp->language_defn)
{
}

exp has already been deleted, which causes the segfault.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug varobj/28131] Segfault in gdbpy_enter_varobj::gdbpy_enter_varobj when debugging in VS Code

[usaonmonday at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=28131

Andrey Sotnikov <usaonmonday at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tromey at sourceware dot org

--- Comment #1 from Andrey Sotnikov <usaonmonday at gmail dot com> ---
I ran a quick binary search and found the culprit commit:

SHA-1: 24fd95b4cd40f0108299c02f31f2d2a129f83769

* Change varobj_dynamic::child_iter to unique_ptr

This changes varobj_dynamic::child_iter to be a unique_ptr, removing
some manual management.

gdb/ChangeLog
2020-12-11  Tom Tromey  <tom@tromey.com>

        * varobj.c (struct varobj_dynamic) <child_iter>: Now unique_ptr.
        (varobj_get_iterator): Return unique_ptr.
        (update_dynamic_varobj_children, install_visualizer)
        (varobj::~varobj): Update.
        * python/python-internal.h (py_varobj_get_iterator): Return
        unique_ptr.
        * python/py-varobj.c (py_varobj_get_iterator): Return unique_ptr.


Adding Tom to CC.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug varobj/28131] Segfault in gdbpy_enter_varobj::gdbpy_enter_varobj when debugging in VS Code

[ssbssa at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=28131

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 varobj/28131] Segfault in gdbpy_enter_varobj::gdbpy_enter_varobj when debugging in VS Code

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=28131

Tom Tromey <tromey at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at sourceware dot org   |tromey at sourceware dot org
   Target Milestone|---                         |11.1

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug varobj/28131] Segfault in gdbpy_enter_varobj::gdbpy_enter_varobj when debugging in VS Code

[simark at simark dot ca]

https://sourceware.org/bugzilla/show_bug.cgi?id=28131

Simon Marchi <simark at simark dot ca> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |simark at simark dot ca

--- Comment #2 from Simon Marchi <simark at simark dot ca> ---
Does VSCode give you a way to see the MI traffic between it and GDB?  If so,
could you share that?  It would make it easier to reproduce.  If you can give
the source of the debugged program, even better.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug varobj/28131] Segfault in gdbpy_enter_varobj::gdbpy_enter_varobj when debugging in VS Code

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=28131

Tom Tromey <tromey at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2021-07-30

--- Comment #3 from Tom Tromey <tromey at sourceware dot org> ---
It took a little while but I figured out how to reproduce this today.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug varobj/28131] Segfault in gdbpy_enter_varobj::gdbpy_enter_varobj when debugging in VS Code

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=28131

--- Comment #4 from Tom Tromey <tromey at sourceware dot org> ---
https://sourceware.org/pipermail/gdb-patches/2021-July/181277.html

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug varobj/28131] Segfault in gdbpy_enter_varobj::gdbpy_enter_varobj when debugging in VS Code

[usaonmonday at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=28131

--- Comment #5 from Andrey Sotnikov <usaonmonday at gmail dot com> ---
Thanks for taking care of it!

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug varobj/28131] Segfault in gdbpy_enter_varobj::gdbpy_enter_varobj when debugging in VS Code

[cvs-commit at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=28131

--- Comment #6 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Tom Tromey <tromey@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=4d0754c5f572b01cf2fe6c8ab292adba83331cbc

commit 4d0754c5f572b01cf2fe6c8ab292adba83331cbc
Author: Tom Tromey <tromey@adacore.com>
Date:   Fri Jul 30 11:18:36 2021 -0600

    Avoid crash in varobj deletion

    PR varobj/28131 points out a crash in the varobj deletion code.  It
    took a while to reproduce this, but essentially what happens is that a
    top-level varobj deletes its root object, then deletes the "dynamic"
    object.  However, deletion of the dynamic object may cause
    ~py_varobj_iter to run, which in turn uses gdbpy_enter_varobj:

    gdbpy_enter_varobj::gdbpy_enter_varobj (const struct varobj *var)
    : gdbpy_enter (var->root->exp->gdbarch, var->root->exp->language_defn)
    {
    }

    However, because var->root has already been destroyed, this is
    invalid.

    I've added a new test case.  This doesn't reliably crash, but the
    problem can easily be seen under valgrind (and, I presume, with ASAN,
    though I did not try this).

    Tested on x86-64 Fedora 32.  I also propose putting this on the GDB 11
    branch, with a suitable ChangeLog entry of course.

    Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28131

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug varobj/28131] Segfault in gdbpy_enter_varobj::gdbpy_enter_varobj when debugging in VS Code

[cvs-commit at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=28131

--- Comment #7 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The gdb-11-branch branch has been updated by Tom Tromey
<tromey@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=3e5ec878a43ac06624a2cc816a329d9b22b95cac

commit 3e5ec878a43ac06624a2cc816a329d9b22b95cac
Author: Tom Tromey <tromey@adacore.com>
Date:   Fri Jul 30 11:18:36 2021 -0600

    Avoid crash in varobj deletion

    PR varobj/28131 points out a crash in the varobj deletion code.  It
    took a while to reproduce this, but essentially what happens is that a
    top-level varobj deletes its root object, then deletes the "dynamic"
    object.  However, deletion of the dynamic object may cause
    ~py_varobj_iter to run, which in turn uses gdbpy_enter_varobj:

    gdbpy_enter_varobj::gdbpy_enter_varobj (const struct varobj *var)
    : gdbpy_enter (var->root->exp->gdbarch, var->root->exp->language_defn)
    {
    }

    However, because var->root has already been destroyed, this is
    invalid.

    I've added a new test case.  This doesn't reliably crash, but the
    problem can easily be seen under valgrind (and, I presume, with ASAN,
    though I did not try this).

    Tested on x86-64 Fedora 32.  I also propose putting this on the GDB 11
    branch, with a suitable ChangeLog entry of course.

    Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28131

    (cherry picked from commit 4d0754c5f572b01cf2fe6c8ab292adba83331cbc)

    gdb/ChangeLog
    2021-08-02  Tom Tromey  <tromey@adacore.com>

            PR varobj/28131
            * varobj.c (~varobj): Delete 'dynamic' before 'root'.

    gdb/testsuite/ChangeLog
    2021-08-02  Tom Tromey  <tromey@adacore.com>

            PR varobj/28131
            * gdb.python/py-mi-var-info-path-expression.exp: Add regression
            test.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug varobj/28131] Segfault in gdbpy_enter_varobj::gdbpy_enter_varobj when debugging in VS Code

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=28131

Tom Tromey <tromey at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED

--- Comment #8 from Tom Tromey <tromey at sourceware dot org> ---
Fixed.

-- 
You are receiving this mail because:
You are on the CC list for the bug.