search

microsoft / vscode-cpptools

Official repository for the Microsoft C/C++ extension for VS Code.
Other
5.51k stars 1.55k forks source link

Cannot debug a c++ program: "Program received signal SIGSEGV, Segmentation fault." #7414

Closed tomatac closed 3 years ago

tomatac commented 3 years ago

Bug type: Debugger

Describe the bug

To Reproduce Please include a code sample and launch.json configuration. Steps to reproduce the behavior:

  1. run the debugger to the first line of code of the main program (cout << "Hello World\n";)
  2. get a multiple faults in a loop: Program received signal SIGSEGV, Segmentation fault. __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:65
  3. it happens for multiple programs that used to work
  4. if I run gdb, from the terminal, inside vs code, debugging is normal

Do you have any suggestions to troubleshoot this issue?

Additional context image

image

Running within a container. See also: https://github.com/microsoft/vscode-dev-containers/issues/827

sean-mcmanus commented 3 years ago

This doesn't seem like an issue with our extension. I assume it would crash when you run the app from the command line, right? It seems like some issue with your compiler, libraries, or runtime.

Chuxel commented 3 years ago

@sean-mcmanus The strange thing is that it appears to run fine from the terminal based on this comment:

if I run gdb, from the terminal, inside vs code, debugging is normal

This was originally raised as microsoft/vscode-dev-containers#827 where it happened from inside a development container that should give a consistent toolchain. I am not able to repro.

tomatac commented 3 years ago

I think it is an issue with the interface between the VS Code and gdb that is particular to this project (folder in VS Code). The gdb works fine from a terminal inside the VS Code. If not debugged the program runs fine from VS Code. It does not seam to be related to the container as I stripped down the container to the basics and it is still happening. The same container configuration in a different project works fine. Debugging used to work in this project. It looks like something got corrupted and it stooped working.

It is interesting that when I choose the debug option I can see some Launch options from my old configuration, when my launch.json has only one configuration "Build Main" copied from the vscode-remote-try-cpp".

image

Is VS Code cashing some data that can affect debugging?

Is there a way to troubleshoot the VS Code debugger?

tomatac commented 3 years ago

I uninstalled / reinstalled VS Code and it is still not working.

tomatac commented 3 years ago

Deleting all files and sub-folders from this folder solved the issue: ~/.config/Code Obviously I lost my configuration settings

tomatac commented 3 years ago

The same issue appeared again as I was just stepping through the program using the VS Code debugger. Some UI clues when that happens:

image

image

image

sean-mcmanus commented 3 years ago

@tomatac Do you have expressions in the watch Window that when evaluated could cause your program to crash when evaluated?

@WardenGnaw Do you think this could be a C/C++ debugger bug?

tomatac commented 3 years ago

I am not sure if i had anything in the watch window. If it was any variable, it was something simple (not an expression). It looks like when the crash appear, to recover and be able to debug again, the fix is to erase all VS Code settings. I could try to erase just part of the settings and see what setting makes the debugger crash. Do you know what settings (files, folder, ...) could be linked to the debugger?

sean-mcmanus commented 3 years ago

I don't know of any debugger settings that could affect this, other than launch.json. @WardenGnaw might.

tomatac commented 3 years ago

Deleting all files and sub-folders from this folder solved the issue: ~/.config/Code Typically the launch.json is typically stored with the project and that did not seam to have an influence on this specific issue.

sean-mcmanus commented 3 years ago

Yeah, I'm not aware of any debugger extension data that is cached at ~/.config/Code by our extension, so I'm guessing maybe VS Code itself might have stored something there that caused the issue?

WardenGnaw commented 3 years ago

The only customizations I am aware of are gdb init file or customizations to launch the debugger in launch.json with setupCommands.

WardenGnaw commented 3 years ago

Closing due to it being cause by external folders.

cffjob commented 1 year ago

@tomatac Do you have expressions in the watch Window that when evaluated could cause your program to crash when evaluated?

@WardenGnaw Do you think this could be a C/C++ debugger bug?

I encountered the same problem. There is a variable in the watch window, the problem disappears after I deleting the variable in the watch window. Thanks.

Orbitoly commented 1 year ago

Encountered the same, solved by removing all breakpoints.

larsbs commented 1 year ago

@tomatac Do you have expressions in the watch Window that when evaluated could cause your program to crash when evaluated? @WardenGnaw Do you think this could be a C/C++ debugger bug?

I encountered the same problem. There is a variable in the watch window, the problem disappears after I deleting the variable in the watch window. Thanks.

I can confirm I had a variable in the watch window that I hadn't added there, and deleting it fixed the issue.

heddxh commented 5 months ago

I can confirm I had a variable in the watch window that I hadn't added there, and deleting it fixed the issue.

Same here. Should it be re opened? Watching an non-exist variable should not lead to segmentation fault and interruprt the debugger.

programmer-04 commented 1 month ago

I can confirm I had a variable in the watch window that I hadn't added there, and deleting it fixed the issue.

Same here. Should it be re opened? Watching an non-exist variable should not lead to segmentation fault and interruprt the debugger.

I agree that it should be reopened. I spent a long time trying to find what's wrong.