GDB crashes under visual-studio-code with internal error

[peterazmanov]

Debugger can't pass certain point in my program, while debugging under visual-studio-code. If I run the session in terminal (outside of IDE) everything works normal. In simplified version debugger crashes only when entering the problem function. Here is output from VS code debug console:

GNU gdb (GDB) 7.11.1
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
Stopped due to shared library event (no libraries added or removed)
Breakpoint 1, main () at main.cpp:18
18      std::cout << "Test!" << std::endl;
Breakpoint 2, main () at main.cpp:26
26      read_record(dataset);
Execute debugger commands using "-exec <command>", for example "-exec info registers" will list registers in use (when GDB is the debugger)
Breakpoint 3, main () at main.cpp:27
27      return 0;
Kill the program being debugged? (y or n) [answered Y; input not from terminal]
The program '/home/pa/work/vsc-test/a.out' has exited with code 0 (0x00000000).

Here is simplified self contained code (test.txt must contain at least 4 bytes):

#include <iostream>
#include <fstream>
#include <vector>

std::vector<uint8_t> read_record( std::istream & stream )
{
    if (!stream)
        return std::vector<uint8_t>();

    std::vector<uint8_t> result(4);
    stream.read(reinterpret_cast<char *>(result.data()), 4);

    return std::move(result);
}

int main()
{
    std::cout << "Test!" << std::endl;

    char const * file_name = "test.txt";

    std::ifstream dataset(file_name);
    if (!dataset)
        throw std::runtime_error(std::string(file_name) + ": error: can't open dataset!");

    read_record(dataset);
    return 0;
}

Problem function: read_record

System Arch Linux 4.6.3-1
Visual Studio Code 1.3.1
C/C++ extension 0.7.1
g++ (GCC) 6.1.1 20160602

[pieandcakes]

@peterazmanov I tried your scenario on Ubuntu 14.04 /w GDB 7.7.1. I compiled the above code with "g++ -g main.cpp -std=c++11" and then setting the breakpoints you are showing above. I'm able to step in and debug through the read_record method.

I'll attempt to setup an Arch Linux machine to see if I can repro on that.

[peterazmanov]

After system update (4.6.4-1) and extension update (0.8.0), the sample crashes.
Output:

=thread-group-added,id="i1"
GNU gdb (GDB) 7.11.1
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
Stopped due to shared library event (no libraries added or removed)
Loaded '/lib64/ld-linux-x86-64.so.2'. Symbols loaded.
Breakpoint 1, main () at main.cpp:18
18      std::cout << "Test!" << std::endl;
Breakpoint 2, main () at main.cpp:26
26      read_record(dataset);
Loaded '/usr/lib/libstdc++.so.6'. Symbols loaded.
Loaded '/usr/lib/libm.so.6'. Symbols loaded.
Loaded '/usr/lib/libgcc_s.so.1'. Symbols loaded.
Loaded '/usr/lib/libc.so.6'. Symbols loaded.
Execute debugger commands using "-exec <command>", for example "-exec info registers" will list registers in use (when GDB is the debugger)
value.c:824: internal-error: value_contents_bits_eq: Assertion `offset1 + length <= TYPE_LENGTH (val1->enclosing_type) * TARGET_CHAR_BIT' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) [answered Y; input not from terminal]
value.c:824: internal-error: value_contents_bits_eq: Assertion `offset1 + length <= TYPE_LENGTH (val1->enclosing_type) * TARGET_CHAR_BIT' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Create a core file of GDB? (y or n) [answered Y; input not from terminal]
ERROR: GDB exited unexpectedly. Debugging will now abort.
The program '/home/pa/work/vsc-test/a.out' has exited with code -1 (0xffffffff).

[pieandcakes]

@peterazmanov I reproed your issue on Arch Linux and it seems to be a bug in GDB. We communicate with GDB using the MI interface and when we step into read_record, we call -stack-list-arguments to update the UI with the arguments list information for the stack. This seems to cause the error you see in your latest log:

value.c:824: internal-error: value_contents_bits_eq: Assertion `offset1 + length <= TYPE_LENGTH (val1->enclosing_type) * TARGET_CHAR_BIT' failed.
A problem internal to GDB has been detected,

I don't know if this has to do with a change within gdb between 7.7(version on Ubuntu) and 7.11 (version on Arch Linux) or if the Arch Linux version has a change that isn't on the mainline.

[delmyers]

@pieandcakes
Can you verify that the same thing happens inside GDB? That is, step into the method, and then call the same command -stack-list-arguments and see if the debuggee quits? If it does, then there is, unfortunately nothing we can do about this other than file a bug against GDB.

[pieandcakes]

@delmyers Yes, the same thing happens in GDB when I call -stack-list-arguments in that block of code. unfortunately there isn't a non-mi command that I can verify this in regular mode GDB.

[peterazmanov]

I downgraded GDB to version 7.7.1 and the sample stopped crashing. I can now debug my program. Another problem which I encountered recently with the newest gdb has gone too (trying to stop on breakpoint GDB freezes, eats all memory and crashes). I didn't test versions between 7.7.1 and 7.11.1, maybe there is a newer version not affected by this bug.

[mlimber]

I had a similar issue. Debugging with gdb was fine. Using gdb within vscode would report an error like the OP's. Attempting to downgrade gdb induced other problems with gdb (I was on 7.12.4 and tried going back to 7.7.1), so I gave up on that path. I realized that I had some old watches and breakpoints set in vscode. I cleared all those out and -- ba-da-bing -- it started working again. YMMV.

[pieandcakes]

@mlimber Can you tell me which OS you are running on?

[mlimber]

@pieandcakes, I'm also on Arch Linux, which is code for running the latest version of virtually every Linux package. Specifically:

Linux localhost 4.10.4-1-ARCH #1 SMP PREEMPT Sat Mar 18 19:39:18 CET 2017 x86_64 GNU/Linux

vscode version 1.10.2
g++ version 6.3.1
gdb version 7.12.1