Skip to content
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

Debugger hangs on break if dbgsym packages are installed, SourceRequest #3662

Open
rpavlik opened this issue May 17, 2019 · 4 comments

Comments

Projects
None yet
3 participants
@rpavlik
Copy link

commented May 17, 2019

Issue Type: Bug

I'm on Debian Testing/Buster. The project I was working on when hitting this bug was SolveSpace - will attach the launch config (I had it set to break on a glib warning, which one occurs when you go to exit the app). But I don't expect those specifics to matter too much.

Initially, I had function names for a number of stack frames, but they were greyed out (just like, e.g. raise.c from the c library is) and couldn't click them. I wanted to look a bit closer so I went to add the debug symbols - apparently they're in a separate apt repo now - so I added deb http://debug.mirrors.debian.org/debian-debug/ testing-debug main to my sources and installed libgtk-3-0-dbgsym libglib2.0-0-dbgsym libglibmm-2.4-1v5-dbgsym and tried the debug again.

Now, most of the greyed-out ones are no longer greyed (presumably because of the dbgsym packages). However, the debugger hangs (can't continue, view other stack frames, etc - can only hit "stop" and that doesn't actually close the app) as soon as it breaks in a place that is related to those symbol packages. It appears to be trying to load something and failing (it shows an error "Stopping due to fatal error: NotImplementedException: No handler implemented for request type 'SourceRequest'" in the debug console), but can't even view the stack frames I know I have source for.

Can't debug with extensions disabled, which is why I'm filing this here.

Here's the launch config I used for my SolveSpace build, it automatically triggers breakpoints on some warning messages in glib, which are getting triggered on exit.
launch.zip

This is what it looks when misbehaving after installing the symbols:
image

Note that most stack frames aren't greyed out, the "NotImplementedException" in the debug console, and the attempt to open a source file (from the libraries I installed dbgsym for) causing an activity-bar to keep scrolling.

Clicking stack frames does nothing but switch to another file it can't show me. The "Load more stack frames" button does nothing, as do attempting to expand the other threads' call tacks.

Here are two screen casts: one showing what happens when the dbgsym packages are installed (at the end, I show how the stop button didn't actually stop the debugged application), the other showing it working more correctly after I uninstalled them.
debugger-screencasts.zip

and here's the launch.json for this exact reproduction, though I suspect any library that is system-installed and has the ability to break on some condition might cause the same thing.
launch.zip

Extension version: 0.23.1
VS Code version: Code - Insiders 1.34.0-insider (daf71423252a707b8e396e8afa8102b717f8213b, 2019-05-07T05:14:45.885Z)
OS version: Linux x64 4.19.0-4-amd64

System Info
Item Value
CPUs AMD Ryzen 7 2700X Eight-Core Processor (16 x 3684)
GPU Status 2d_canvas: enabled
checker_imaging: disabled_off
flash_3d: enabled
flash_stage3d: enabled
flash_stage3d_baseline: enabled
gpu_compositing: enabled
multiple_raster_threads: enabled_on
native_gpu_memory_buffers: disabled_software
rasterization: disabled_software
surface_synchronization: enabled_on
video_decode: unavailable_off
webgl: enabled
webgl2: enabled
Load (avg) 2, 2, 1
Memory (System) 15.62GB (0.57GB free)
Process Argv .
Screen Reader no
VM 0%
@pieandcakes

This comment has been minimized.

Copy link
Collaborator

commented May 21, 2019

@rpavlik Thank you for reporting this. Does this happen quite consistently for you? if so, can you do me a favor and get me a traceResponse log for when it happens? To do that, you would want to add "logging": {"traceResponse": true} to your launch.json and restart debugging.

AFAIK we don't support SourceRequest (which is what the exception is) but I can't understand why VS Code is sending us the request in the first place.

If you don't want to post it here but you are comfortable emailing it to me, my email address is in my profile.

@rpavlik

This comment has been minimized.

Copy link
Author

commented May 22, 2019

Well, I'd never had it happen before but I never had those packages installed before. I kept them installed just long enough to record the data.

I re-installed those packages, added the traceResponse config to launch, and it was perfectly reproducible. I got this: (didn't see anything too sensitive - this is all open source code, and I just used solvespace master as of right now.)

traceresponse.txt

@pieandcakes

This comment has been minimized.

Copy link
Collaborator

commented May 22, 2019

Thanks. That helps a lot. I'll see if we can make a fix to avoid stopping debugging.

@pieandcakes pieandcakes changed the title Debugger hangs on break if dbgsym packages are installed Debugger hangs on break if dbgsym packages are installed, SourceRequest May 22, 2019

@pieandcakes pieandcakes added bug and removed investigate labels May 22, 2019

pieandcakes added a commit to microsoft/MIEngine that referenced this issue May 22, 2019

pieandcakes added a commit to microsoft/MIEngine that referenced this issue May 22, 2019

@sean-mcmanus

This comment has been minimized.

Copy link
Collaborator

commented Jun 14, 2019

Fixed with 0.24.0-insiders (available by setting "C_Cpp.updateChannel" to "Insiders").

@sean-mcmanus sean-mcmanus added this to the June 2019 milestone Jun 14, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.