-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GDB crashes under visual-studio-code with internal error #103
Comments
@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. |
After system update (4.6.4-1) and extension update (0.8.0), the sample crashes.
|
@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. 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. |
@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. |
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. |
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. |
@mlimber Can you tell me which OS you are running on? |
@pieandcakes, I'm also on Arch Linux, which is code for running the latest version of virtually every Linux package. Specifically:
vscode version 1.10.2 |
Has there been any update on this issue? Was there an issue filed with GDB? |
I also tried downgrading GDB to 7.7.1, which did not help. |
Any update on this issue? I'm using gdb version 8.1 on Arch Linux and are still encouturing this issue. |
Same here. I don't have any issue if I run gdb from shell. In VSCode it crashes, tho. |
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. |
I'm using gdb version 8.1 on Windows7 64bit , when a function have a return value, i use step out ,it crashes. |
@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. |
Similar issue with gdb and Visual Code Studio here:
Ubuntu 16.04 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 Potentially helpful information when I run the command via gdb from terminal (successfully):
|
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 My launch.json file: |
@rytisss Do you have a repro project you can share for your scenario? |
This is an older issue and hasn't had any updates. Please comment/open a new issue if it is still happening. |
Fix Windows VS Code debugging with new CoreCLR-based OpenDebugAD7
I was having the same issue whenever I try to add a legitimate watch expression or execute a command in debug console. Even the Variables Tab in Run and Debug, shows value of
Switching to mingw-32 gdb this works fine. |
|
Have the same issue with Works excellent if I use gdb in a terminal window. |
@richardh538 I just ran into this as well, with a similar set of tools versions. It seems that the issue has been fixed in GDB but the fix isn't in Ubuntu repositories yet: #9135 (comment). |
To temporarily solve this until its updated in ubuntu 22.04 repos you can:
If you use multiarch, also check @jimfred post below. Edit: By now there is a proposed update to gdb12.1-0 for 22.04 jammy here: https://launchpad.net/ubuntu/+source/gdb/12.1-0ubuntu1~22.04 or you can add the toolchain build to your software sources: https://launchpad.net/~ubuntu-toolchain-r/+archive/ubuntu/ppa |
In addition to the
|
Related on Stack Overflow: Why GDB is crashing my program when break point is hit when using it from VSCode? |
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:
Here is simplified self contained code (test.txt must contain at least 4 bytes):
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
The text was updated successfully, but these errors were encountered: