module containing this breakpoint has not yet loaded on setting breakpoints

[brentgracey]

I've been unable to track down my mistake - although I'm sure this is a setup issue on my side.

I am connecting to a container; and mounting the code in the same directory as on the host PC: -v /home/brent/repos/Open3D:/home/brent/repos/Open3D

I've built the code in the container; not via vscode; and am trying to launch and debug an executable. The executable launches; but whenever I set a breakpoint it goes clear and I get the hover over message: module containing this breakpoint has not yet loaded

Debug output:

Launch configuration:
{
  "name": "g++-9 - Launch visualizer",
  "type": "cppdbg",
  "request": "launch",
  "program": "/home/brent/repos/Open3D/build/bin/examples/Visualizer",
  "args": [
    "pointcloud",
    "/home/brent/repos/Open3D/examples/test_data/fragment.ply"
  ],
  "stopAtEntry": false,
  "cwd": "/home/brent/repos/Open3D/build",
  "environment": [],
  "externalConsole": false,
  "MIMode": "gdb",
  "sourceFileMap": {
    "/home/brent/repos/Open3D": "/home/brent/repos/Open3D"
  },
  "setupCommands": [
    {
      "description": "Enable pretty-printing for gdb",
      "text": "-enable-pretty-printing",
      "ignoreFailures": true
    }
  ],
  "preLaunchTask": "C/C++: g++-9 build active file",
  "miDebuggerPath": "/bin/gdb",
  "logging": {
    "trace": true,
    "traceResponse": true,
    "engineLogging": true,
    "exceptions": true,
    "moduleLoad": true,
    "programOutput": true
  },
  "__configurationTarget": 5
}
cpptools/fileCreated: file:///home/brent/repos/Open3D/.vscode/launch
cpptools/fileDeleted: file:///home/brent/repos/Open3D/.vscode/launch
Checking for syntax errors: file:///home/brent/repos/Open3D/examples/cpp/Visualizer.cpp
Queueing IntelliSense update for files in translation unit of: /home/brent/repos/Open3D/examples/cpp/Visualizer.cpp
cpptools/finishUpdateSquiggles
Error squiggle count: 0
Error squiggle count: 0
Update IntelliSense time (sec): 0.29
cpptools/getSemanticTokens: file:///home/brent/repos/Open3D/examples/cpp/Visualizer.cpp (id: 318)
cpptools/getSemanticTokens: file:///home/brent/repos/Open3D/cpp/open3d/geometry/TriangleMesh.h (id: 319)

In the container; I am able to hit a breakpoint if I launch the executable with gdb directly

root@f521657f69ae:/home/brent/repos/Open3D/build/bin/examples# gdb Visualizer                                                                    
GNU gdb (Ubuntu 9.2-0ubuntu1~20.04) 9.2
Copyright (C) 2020 Free Software Foundation, Inc.
Type "apropos word" to search for commands related to "word"...
Reading symbols from Visualizer...
(gdb) 
(gdb) b main
Breakpoint 1 at 0x13ad52
(gdb) info b
Num     Type           Disp Enb Address            What
1       breakpoint     keep y   0x000000000013ad52 <main>
(gdb) run pointcloud /home/brent/repos/Open3D/examples/test_data/fragment.ply
Starting program: /home/brent/repos/Open3D/build/bin/examples/Visualizer pointcloud /home/brent/repos/Open3D/examples/test_data/fragment.ply
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Breakpoint 1, 0x000055555568ed52 in main ()
(gdb) where
#0  0x000055555568ed52 in main ()

Extension version: 1.1.3 VS Code version: Code 1.52.0 (940b5f4bb5fa47866a54529ed759d95d09ee80be, 2020-12-10T22:43:50.597Z) OS version: Linux x64 5.4.0-54-generic snap Remote OS version: Linux x64 5.4.0-54-generic

System Info

|Item|Value| |---|---| |CPUs|AMD Ryzen Threadripper 3960X 24-Core Processor (48 x 2200)| |GPU Status|2d_canvas: unavailable_software
flash_3d: disabled_software
flash_stage3d: disabled_software
flash_stage3d_baseline: disabled_software
gpu_compositing: disabled_software
multiple_raster_threads: enabled_on
oop_rasterization: disabled_off
opengl: disabled_off
protected_video_decode: disabled_off
rasterization: disabled_software
skia_renderer: enabled_on
video_decode: disabled_software
vulkan: disabled_off
webgl: unavailable_software
webgl2: unavailable_software| |Load (avg)|1, 1, 1| |Memory (System)|62.75GB (20.40GB free)| |Process Argv|--force-user-env --no-sandbox --unity-launch --no-sandbox --crash-reporter-id 205183f6-0566-4829-8349-b40996aca137| |Screen Reader|no| |VM|0%| |DESKTOP_SESSION|ubuntu| |XDG_CURRENT_DESKTOP|Unity| |XDG_SESSION_DESKTOP|ubuntu| |XDG_SESSION_TYPE|x11| |Item|Value| |---|---| |Remote|Container open3d:1.0 (/quirky_archimedes)| |OS|Linux x64 5.4.0-54-generic| |CPUs|AMD Ryzen Threadripper 3960X 24-Core Processor (48 x 2200)| |Memory (System)|62.75GB (20.40GB free)| |VM|0%|

A/B Experiments

``` vsliv368cf:30146710 vsreu685:30147344 openlogontheside:30221877 python763:30178808 python383:30185418 vspor879:30202332 vspor708:30202333 vspor363:30204092 python504:30227505 vswsl492:30211401 wsl2prompt:30224612 pythonvsdeb440:30233463 unusedprompt:30224610 folderexplorercf:30224615 openfilemenucf:30224648 vsjup459cf:30229594 ```

[WardenGnaw]

Can you enable logging and share the output from Debug Console?

With just the following logging enabled:

"logging": {
   "engineLogging": true,
   "traceResponse": true
}

---

Possible fix:

If you have:

"sourceFileMap": {
    "/home/brent/repos/Open3D": "/home/brent/repos/Open3D"
  },

It will use fully qualified breakpoints with the file path, so it would do b -f /path/to/file/with/main/file.c:<line> If you don't want the fully qualified file path, and just want b main you want to change the sourceFileMap to be :

"sourceFileMap": {
    "/home/brent/repos/Open3D": {
       "editorPath" : "/home/brent/repos/Open3D",
      "useForBreakpoints" : false
  },

[brentgracey]

Hi Andrew; thank you for helping me troubleshoot!!

I had added "sourceFileMap" to see if it would resolve the issue; so its value was just my first guess of what to set it. Removing the "sourceFileMap" setting completely or updating it to your suggestion all have the same result of "Module containing this breakpoint has not yet loaded or the breakpoint address could not be obtained."

I had not enabled debug logging in the container; so there are now lots more lots; PFA file.

c++debuglogs.txt

Could any of the below points be worth looking into:

I'm only building the executable; and executing it out of the build folder; the project does have an install step too; which I have not run yet. For reference its: http://www.open3d.org/docs/release/compilation.html#build

Perhaps I could mount the repo & build folders into a different location in the container? I can change the -v /home/brent/repos/Open3D:/home/brent/repos/Open3D

Are there different ways for me to specify how to launch the executable? "program": "${workspaceRoot}/build/bin/examples/Visualizer" does work; but for example; just providing the absolute path doesn't.

Thanks again; hoping its not too much of a stupid mistake from my side; but feeling it very likely will be.

[WardenGnaw]

From the logs it seems like it can bind main.

1: (1997) <-1011-break-insert -f main
--> E (output): {"type":"event","event":"output","body":{"category":"console","output":"1: (2036) ->1011^done,bkpt={number=\"1\",type=\"breakpoint\",disp=\"keep\",enabled=\"y\",addr=\"0x000000000013ad52\",at=\"<main>\",thread-groups=[\"i1\"],times=\"0\",original-location=\"main\"}\n"},"seq":124}
1: (2036) ->1011^done,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x000000000013ad52",at="<main>",thread-groups=["i1"],times="0",original-location="main"}

Then it is trying to set a breakpoint in Visualizer.cpp line 55 but it can not find the compile time path that it used to build Visualizers.cpp and possibly its line information.

1: (8169) <-1064-break-insert -f Visualizer.cpp:55
--> E (output): {"type":"event","event":"output","body":{"category":"console","output":"1: (8199) ->&\"No source file named Visualizer.cpp.\\n\"\n"},"seq":1384}
1: (8199) ->&"No source file named Visualizer.cpp.\n"
--> E (output): {"type":"event","event":"output","body":{"category":"console","output":"1: (8199) ->1064^done,bkpt={number=\"3\",type=\"breakpoint\",disp=\"keep\",enabled=\"y\",addr=\"<PENDING>\",pending=\"Visualizer.cpp:55\",times=\"0\",original-location=\"Visualizer.cpp:55\"}\n"},"seq":1386}
1: (8199) ->1064^done,bkpt={number="3",type="breakpoint",disp="keep",enabled="y",addr="<PENDING>",pending="Visualizer.cpp:55",times="0",original-location="Visualizer.cpp:55"}

It looks like it is trying to find "Visualizer.cpp" right next to the executable. I'm a bit lost on how exactly it builds the example code, does it move it before compiling so the bin path is different than the original source path?

Just a side note: are you also building it with cmake with the flag -DCMAKE_BUILD_TYPE=Debug?

[brentgracey]

Unfortunately I'm not sure of the correct answers to your questions

I've raised a ticket in the repo I am trying to debug -incase I am not following the correct steps to build with debug symbols https://github.com/intel-isl/Open3D/issues/2774

Thanks again for all your help so far.

[emilian-stoimenov]

The

"sourceFileMap": { "/home/brent/repos/Open3D": { "editorPath" : "/home/brent/repos/Open3D", "useForBreakpoints" : false },

suggestion worked for me. Thank you.

[danielyan86129]

For the this is the key I missed: -DCMAKE_BUILD_TYPE=Debug (Thanks @WardenGnaw ) without it I could still do make my-target but it's not the Debug mode.

[sandilyasg]

@danielyan86129 I understand using the "-DCMAKE_BUILD_TYPE=Debug" command is part of the command-line cmake command you pass to build. Is it possible to directly add this flag in CMakeLists.txt? I am using the ROS catkin build manager.

[Ryanf55]

@danielyan86129 I understand using the "-DCMAKE_BUILD_TYPE=Debug" command is part of the command-line cmake command you pass to build. Is it possible to directly add this flag in CMakeLists.txt? I am using the ROS catkin build manager.

In ROS 2: colcon build --mixin debug OR colcon build --cmake-args -DCMAKE_BUILD_TYPE=Debug

With ROS, make sure you source install/setup.bash before you call GDB. I'm still stuck on how to run that for GDB. Some paths resolve, others don't. It works fine with terminal GDB, just not with VSCode attaching to a process yet. I'll be trying out all the recommendations in this guide, and I'm happy to provide as much debugging info here to the VSCode team as I can.

My use case is a SSH tunnel onto a remote device that doesn't have internet connectivity and it runs ROS 2 in a docker container. It's quite the difficult workflow with VSCode server running on Ubuntu 18.04, but no one on my team understands terminal GDB. Tonight I had the first proof of life of it working.

Edit: For whatever reason, you don't need to call source install/setup.bash when using GDB.