Vscode-cpptools: 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

[hassec]

Has there been any update on this issue? Was there an issue filed with GDB?
I just noticed the same thing running GDB 8.0.1 and a really simple "Hello World" example.

[diiigle]

I also tried downgrading GDB to 7.7.1, which did not help.
Interestingly it works, when I use the second build system of the project I'm building (scons vs cmake). Perhaps there are different compiler settings set, which don't cause the bug in GDB.

[ribomo]

Any update on this issue? I'm using gdb version 8.1 on Arch Linux and are still encouturing this issue.

[nico87]

Same here. I don't have any issue if I run gdb from shell. In VSCode it crashes, tho.

[pieandcakes]

This seems like an older issue. If you are still seeing crashes, please provide the gdb version and a log or snippet of what the error that gdb returns in the log. If this is because of gdb, we will need to file a bug there to have someone fix it.

[Nicolaze]

I'm using gdb version 8.1 on Windows7 64bit , when a function have a return value, i use step out ,it crashes.
vscode version 1.25.0
mingw-w64，x86_64-8.1.0-win32-seh-rt_v6-rev0
g++ version 8.1.0
gdb version 8.1.0

[pieandcakes]

@Nicolaze That seems to be an issue with MinGW 64bit's gdb on 8.1. Unfortunately this is an issue with the toolset and not our extension. Our suggestion would be either to downgrade the version of gdb or if you don't need 64bit, the 32bit version seems to work fine.

[cgebbe]

Similar issue with gdb and Visual Code Studio here:

Stopped due to shared library event (no libraries added or removed)
Loaded '/lib64/ld-linux-x86-64.so.2'. Symbols loaded.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Breakpoint 1, main (argc=2, argv=0x7fffffffdda8, env=0x7fffffffddc0) at /home/my_executable.cpp:75

Ubuntu 16.04
gdb 7.11.1
gcc 5.4.0
vscode 1.27.2

I can start gdb in terminal and run the program in the gdb terminal without issues.

@mlimber : You mentioned that you cleared out old breakpoints and watches. Since I am also seeing a breakpoint: How do you do it? In MY code, I don't have any breakpoints enabled. However, gdb is noticing a breakpoint of a file that I don't even have on my computer. It is from an executable that somebody else built.

// EDIT
I just realized now that I also get a popup stating "unable to open my_executable.cpp", file not found. Which is true, I do not have it, because its a source file from an executable that somebody else built. I am just creating some libraries, which are read by the executable. So the question is: How do I disable such breakpoints?

Potentially helpful information when I run the command via gdb from terminal (successfully):

info breakpoints > No breakpoints or watchpoints (even though the debug console says there is a breakpoint in my_executable::75 ?)
info checkpoints > No checkpoints
info watchpoints > No watchpoints
info sources > A long list of files. Most of the files are NOT existent on my computer. The first row points to my_executable.cpp, which is the file the debug console in visual studio code complains about.

[rytisss]

Similar problem here. It appear only when declaring an object from share library in my main.cpp. without it, everything is fine.

Ubuntu 16.04
gdb 7.11.1
gcc 5.4.0 or 6.4.0
vscode 1.27.2

My launch.json file:
{
// Use IntelliSense to learn about possible attributes.
// Hover to view descriptions of existing attributes.
// For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
"version": "0.2.0",
"configurations": [
{
"name": "(gdb) Launch",
"type": "cppdbg",
"request": "launch",
"program": "${workspaceFolder}/build/TestYolo4Video/TestYolo4Video",
"additionalSOLibSearchPath": "${workspaceFolder}/build/YoloDetector/",
"stopAtEntry": false,
"cwd": "${workspaceFolder}",
"environment": [],
"externalConsole": true,
"MIMode": "gdb",
"logging": { "engineLogging": true },
"setupCommands": [
{
"description": "Enable pretty-printing for gdb",
"text": "-enable-pretty-printing",
"ignoreFailures": true
}
]
}
]
}

[pieandcakes]

@rytisss Do you have a repro project you can share for your scenario?

[pieandcakes]

This is an older issue and hasn't had any updates. Please comment/open a new issue if it is still happening.