Debugger hits breakpoint but sporadically it does not show the associated source

daniel-brosche commented 2 years ago

Does this issue occur when all extensions are disabled?: Yes/No

OS and version: Debian Buster
VS Code: 1.70
C/C++ extension: 1.11.4
GDB version: 12.1 (also with 9.2 reproduced)

Bug Summary and Steps to Reproduce

Bug Summary:

Steps to reproduce:

having an project structure like that /srv/git/cxxx/imports/opc_ua/opc_ua_cxxx_workspace/app.cpp /srv/git/cxxx/imports/opc_ua/opc_ua_cxxx_workspace/src_dir_a/src/src_a.h /srv/git/cxxx/imports/opc_ua/opc_ua_cxxx_workspace/src_dir_a/src/src_a.cpp /srv/git/cxxx/imports/opc_ua/opc_ua_cxxx_workspace/src_dir_b/src/src_b.h /srv/git/cxxx/imports/opc_ua/opc_ua_cxxx_workspace/src_dir_b/src/src_b.cpp

Each of the src dirs results in seprate shared objects that will be loaded dynamicaly by the application.
With the provided config (see debugger configurations)...
Do '...'
- set breakpoint in the different src-dir header-file e.g. src_a.h (shared objects)
- start debugger / application
See error...

gdb hits the breakpoint
sporadically vscode show not the associated source file (33-50% reproducible).
- all debug symbols are loaded correctly
- the fullname in the log is correct (e.g. /srv/git/cxxx/imports/opc_ua/opc_ua_cxxx_workspace/build/../../src_dir_a/src/src_a.h exists)
when I click on the printed path of the debug console then following appears:

with the absolute path of /srv/git/cxxx/imports/opc_ua_cxxx_workspace/src_dir_a/src/src.h

workaround / possible error reasons:

this error seems especially happen with breakpoints in header files (e.g. src_a.h, src_b.h), but also happens from time to time in cpp files
sometimes it seems to help to deactivate / activate all breakpoints and or set more breakpoints in the corresponding cpp files
when I set two breakpoints one in der header and one in cpp-file and the debugger hits the breakpoint in the cpp first (src_a.cpp), then following hit in src_a.h works and the file gets opened in the editor. So I guess it has something to do with the activated breakpoint order and this may affects the path resolution
the log output is always the same:

NOT WORKING 1: (27748) ->*stopped,reason="breakpoint-hit",disp="keep",bkptno="3",frame={addr="0x00007fffb7d8be7c",func="lenze::opc_ua::OpcUaEngBpmServerProviderT::Initialize",args=[{name="this",value="0x7fffc414daf0"},{name="ctx",value="0x7ffff02e6580 <g_providers+448>"}],file="../../opc_ua_eng_bpm_server_provider/src/opc_ua_eng_bpm_server_provider.h",fullname="/srv/git/cxxx/imports/opc_ua/opc_ua_cxxx_workspace/build/../../opc_ua_eng_bpm_server_provider/src/opc_ua_eng_bpm_server_provider.h",line="871",arch="i386:x86-64"},thread-id="33",stopped-threads="all",core="0"

WORKING 1: (35171) ->*stopped,reason="breakpoint-hit",disp="keep",bkptno="4",frame={addr="0x00007fffd7d8be7c",func="lenze::opc_ua::OpcUaEngBpmServerProviderT::Initialize",args=[{name="this",value="0x7fffbc14daf0"},{name="ctx",value="0x7ffff02e6580 <g_providers+448>"}],file="../../opc_ua_eng_bpm_server_provider/src/opc_ua_eng_bpm_server_provider.h",fullname="/srv/git/cxxx/imports/opc_ua/opc_ua_cxxx_workspace/build/../../opc_ua_eng_bpm_server_provider/src/opc_ua_eng_bpm_server_provider.h",line="871",arch="i386:x86-64"},thread-id="33",stopped-threads="all",core="0"

Debugger Configurations

{
        "name": "[TARGET:CPP] GDB SSH",
        "type": "cppdbg",
        "request": "launch",
        "program": "/opt/lenze/bin/runtime",
        "stopAtEntry": false,
        "cwd": "/opt/lib/",
        "environment": [],
        "externalConsole": true,
        "filterStderr": true,
        "filterStdout": true,
        "pipeTransport": {    
            "pipeCwd": "/usr/bin", 
            "pipeProgram": "${workspaceFolder}/ssh.py",
            "debuggerPath": "/usr/bin/gdb" 
        },
        "MIMode": "gdb",
        "setupCommands": [
            {
                "description": "Skip library files",
                "text": "-interpreter-exec console \"skip -gfi **/bits/*.h\""
            }, 
        ]
    },

Debugger Logs

1: (28066) ->*stopped,reason="breakpoint-hit",disp="keep",bkptno="3",frame={addr="0x00007fffb3d8beb6",func="ServerProviderT>::Initialize",args=[{name="this",value="0x7fffbc14d6d0"},{name="ctx",value="0x7ffff02e6580 <g_providers+448>"}],file="../../src_dir_a/src/src.h",fullname="/srv/git/cxxx/imports/opc_ua/opc_ua_cxxx_workspace/build/../../src_dir_a/src/src.h",line="874",arch="i386:x86-64"},thread-id="33",stopped-threads="all",core="0"

I have already created an issue at the cpp extension repository here. After some analysis it seems not to be a problem in the extension or the debugging engine because of the given logs. Instead it seems to be a problem in vscode due to the wrong path resolution.

daniel-brosche commented 2 years ago

One further note: I haven't this problem in the past. So I have tried to re-install older released versions. The same problem appears with version 1.67.2.

Since I have re-installed version 1.64.2 I have no problems anymore.

roblourens commented 2 years ago

Not clear what the exact steps are... you break on an exception, then what happens? when I click on the printed path of the debug console then following appears you are clicking on a link in the debug console? Or is this just about hitting a breakpoint and clicking that file in the callstack? I put together some basic test cases for both scenarios and it all works as expected for me.

roblourens commented 2 years ago

Also, I'm not sure that log is so conclusive, it is not showing the actual DAP messages sent back to vscode, but a gdb message or some other intermediate format. I'm curious whether this debug adapter has a way to get the actual DAP @WardenGnaw

WardenGnaw commented 2 years ago

In your launch.json where engineLogging: true was added, replace it with traceResponse: true.

E.g.

...
"MIMode": "gdb",
"setupCommands": []
"logging": {
   "traceResponse": true
}

daniel-brosche commented 2 years ago

I have this issue again. For a while this issue was not easly reproducible but now it happens each time again.

Version: 1.64.2 Commit: f80445acd5a3dadef24aa209168452a3d97cc326 Date: 2022-02-09T22:02:29.527Z Electron: 13.5.2 Chromium: 91.0.4472.164 Node.js: 14.16.0 V8: 9.1.269.39-electron.0 OS: Linux x64 4.19.0-21-amd64

CPP Extension: v1.10.5

It seems to have something to do with some internal state. Same Breakpoint as described above traced with "traceResponse": true

--> E (output): {"type":"event","event":"output","body":{"category":"stdout","output":"Thread 27 \"LUaMain\" hit Breakpoint 2, lenze::opc_ua::OpcUaEngBpmServerProviderT<lenze::opc_ua::EngBpmDataProvider>::Initialize (this=0x7fffd014b400, ctx=0x7ffff023e580 <g_providers+448>) at ../../opc_ua_eng_bpm_server_provider/src/opc_ua_eng_bpm_server_provider.h:871\n"},"seq":5657}
Thread 27 "LUaMain" hit Breakpoint 2, lenze::opc_ua::OpcUaEngBpmServerProviderT<lenze::opc_ua::EngBpmDataProvider>::Initialize (this=0x7fffd014b400, ctx=0x7ffff023e580 <g_providers+448>) at ../../opc_ua_eng_bpm_server_provider/src/opc_ua_eng_bpm_server_provider.h:871

when I click on ../../opc_ua_eng_bpm_server_provider/src/opc_ua_eng_bpm_server_provider.h:871 then it tries to open /srv/git/cxxx/imports/opc_ua_eng_bpm_server_provider/src/opc_ua_eng_bpm_server_provider.h but the original file is located here /srv/git/cxxx/imports/opc_ua/opc_ua_eng_bpm_server_provider/src/opc_ua_eng_bpm_server_provider.h

so the correct parent directory is imports/opc_ua but instead vscode opens the parent directory of the parent directory imports. (parent directory of the correct parent directory)

daniel-brosche commented 2 years ago

when I click on the printed path of the debug console then following appears I click the path printed in the debug console.

Since I have re-installed version 1.64.2 I have no problems anymore. For a while seems to be gone with this version but now it also appears regularly.

roblourens commented 2 years ago

So you are clicking on the exact text ../../opc_ua_eng_bpm_server_provider/src/opc_ua_eng_bpm_server_provider.h:871 in the debug console, and it isn't able to open the path?

It seems that links that start with .. are not handled correctly, I think we just drop the .. in my test. But there are definitely some issues with link detection, I have this issue to handle them in general: https://github.com/microsoft/vscode/issues/34026

daniel-brosche commented 2 years ago

So you are clicking on the exact text ../../opc_ua_eng_bpm_server_provider/src/opc_ua_eng_bpm_server_provider.h:871 in the debug console, and it isn't able to open the path?

Yes, correct

daniel-brosche commented 2 years ago

I have figured out, that even when the breakpoint hits and vscode shows the corresponding source file the link does not work either.

microsoft / vscode