VisualGDB Python module remote debug problems / JETSON TX2

[julienmercenier]

Hi,

First, I can run and remote debug a C++ project using the same IP/SSH configurations.

I’ve tried, without success, to remote debug a python module (cpp) project and a pure python project.

I managed to create both projects without problems followings some guidelines from this website/forum and can see my debug prints in the console.

Python project: Linux Project Wizard -> Python-base -> Python code only -> default GCC-based toolchain on …  breakpoints in C/C++ and Python

Python module project : Linux Project Wizard -> Python-base -> GNU Make (language standard C++) breakpoints in C/C++ > Python executable :python and  Python include folder (detect automatically)

VisualGDB version: 5.4.104.3031
—————— System.NullReferenceException ——————
System.NullReferenceException: Object reference not set to an instance of an object.
at oy.y.d_2()
at bp1.Delete()

 

None of those projects allow me set any breakpoint in the python code.Nevertheless, in the python module project, I can set a breakpoint in the C++ code.

I’ve tried with python2.7, python 3.5 and python 3.6.

Target platform : NVIDIA JETSON TX2 running a linux tegra-ubuntu (16.04.5 LTS) aarch64

VisualGDB: 5.4R4 (build 3031)

 

Best regards,

Julien

 

[support]

Thanks for the detailed description. The error looks like a race condition between ending the GDB session and cleaning up the breakpoint. It should normally not interfere with the rest of debugging.

Either way, we have fixed it here: VisualGDB-5.4.104.3035.msi

If the breakpoint still does not trigger, please share a gdb session log file and also the output from View->Other Windows->VisualGDB Diagnostics Console along with more details (the path of the .py file where you try to set the breakpoint).

Please also let us know if the Python frames in the Call Stack are shown correctly (i.e. with code locations) when hitting a breakpoint in the C++ module.

[julienmercenier]

Hi, thank you for the answer.

Unfortunately,VisualGDB-5.4.104.3035.msi does not solve any probem.

As requested

<hr />

VisualGDB launcher Output

VisualGDB: Executing postdebug actions
Found 0 .natvis files in the current project
VisualGDB: Executing predebug actions
VisualGDB: Launching gdb
VisualGDB: Run “gdb –interpreter mi –args “python” “/tmp/com_sysprogs_PythonDebugWrapper.py” “/tmp/com_sysprogs_PythonBreakpointModule.so” $(SourceDir)/../Scripts/Test_ApiGeneral.py ” in directory “$(TargetDir)” on nvidia@172.16.6.79 (SSH)
Creating pending breakpoint…

Creating pending breakpoint…

Creating pending breakpoint…

Creating pending breakpoint…

VisualGDB: Executing postdebug actions

 

<hr />

GDB Session log file :

 

<hr />

 

VisualGdb Diagnostic console:

SSH [43]: executing command: export PATH=”/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin” && export QT_QPA_PLATFORMTHEME=”appmenu-qt5″ && export XDG_DATA_DIRS=”/usr/local/share:/usr/share:/var/lib/snapd/desktop” && “test” -d “/tmp/VisualGDB/c/Local/PRO/DT777/MSML/MSML”
SSH [43]: command exited with code 0 after 29 msec
SSH [44]: executing command: cd “/tmp/VisualGDB/c/Local/PRO/DT777/MSML/MSML” && export PATH=”/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin” && export QT_QPA_PLATFORMTHEME=”appmenu-qt5″ && export XDG_DATA_DIRS=”/usr/local/share:/usr/share:/var/lib/snapd/desktop” && export LANG=”en_US.UTF-8″ && “make” CONFIG=Debug
SSH [44]: command exited with code 0 after 50 msec
No deployment host specified for /tmp/VisualGDB/c/Local/PRO/DT777/MSML/MSML/Debug/MSML.so. Skipping…
SSH [45]: executing command: export PATH=”/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin” && export QT_QPA_PLATFORMTHEME=”appmenu-qt5″ && export XDG_DATA_DIRS=”/usr/local/share:/usr/share:/var/lib/snapd/desktop” && “test” -d “/tmp/VisualGDB/c/Local/PRO/DT777/Tests/MSML_PyExt”
SSH [45]: command exited with code 0 after 26 msec
SSH [46]: executing command: cd “/tmp/VisualGDB/c/Local/PRO/DT777/Tests/MSML_PyExt” && export PATH=”/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin” && export QT_QPA_PLATFORMTHEME=”appmenu-qt5″ && export XDG_DATA_DIRS=”/usr/local/share:/usr/share:/var/lib/snapd/desktop” && export LANG=”en_US.UTF-8″ && “make” CONFIG=Debug
SSH [46]: command exited with code 0 after 50 msec
ShouldRedirectToVisualGDBImpl(): C:\Local\PRO\DT777\Tests\MSML_PyExt\MSML_PyExt-Debug.vgdbsettings
Searching for active configuration for MSML_PyExt\MSML_PyExt.vcxproj…
Trying fast lookup…
Found! Configuration name = Debug
Searching for active configuration for MSML_PyExt\MSML_PyExt.vcxproj…
Trying fast lookup…
Found! Configuration name = Debug
Searching for active configuration for ..\MSML\MSML\MSML.vcxproj…
Trying fast lookup…
Found! Configuration name = Debug
Locating deployed dependencies for project…
No deployment host specified for /tmp/VisualGDB/c/Local/PRO/DT777/MSML/MSML/Debug/MSML.so. Skipping…
SSH [47]: executing command: export PATH=”/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin” && export QT_QPA_PLATFORMTHEME=”appmenu-qt5″ && export XDG_DATA_DIRS=”/usr/local/share:/usr/share:/var/lib/snapd/desktop” && “test” -f “/tmp/com_sysprogs_PythonBreakpointModule.so”
SSH [47]: command exited with code 0 after 27 msec
SSH [48]: executing command: export PATH=”/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin” && export QT_QPA_PLATFORMTHEME=”appmenu-qt5″ && export XDG_DATA_DIRS=”/usr/local/share:/usr/share:/var/lib/snapd/desktop” && “test” -f “/tmp/com_sysprogs_PythonDebugWrapper.py”
SSH [48]: command exited with code 0 after 42 msec
SSH [49]: executing command: cd “/tmp/VisualGDB/c/Local/PRO/DT777/Tests/MSML_PyExt/Debug” && stty -echo && export PATH=”/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin” && export QT_QPA_PLATFORMTHEME=”appmenu-qt5″ && export XDG_DATA_DIRS=”/usr/local/share:/usr/share:/var/lib/snapd/desktop” && export LANG=”en_US.UTF-8″ && export PYTHONPATH=”${PYTHONPATH}:/tmp/VisualGDB/c/Local/PRO/DT777/Tests/MSML_PyExt/Debug” && “gdb” –interpreter mi –args “python” “/tmp/com_sysprogs_PythonDebugWrapper.py” “/tmp/com_sysprogs_PythonBreakpointModule.so” /tmp/VisualGDB/c/Local/PRO/DT777/Tests/MSML_PyExt/../Scripts/Test_ApiGeneral.py
Creating a temporary SSH console…
Requesting a temporary console: tty && sleep 2147483647
Searching for active configuration for MSML_PyExt\MSML_PyExt.vcxproj…
Trying fast lookup…
Found! Configuration name = Debug
[+25434] GDB stop event received
[+248] GDB stop event received
SSH [49]: command exited with code 0 after 1794 msec
Searching for active configuration for MSML_PyExt\MSML_PyExt.vcxproj…
Trying fast lookup…
Found! Configuration name = Debug
Searching for active configuration for MSML_PyExt\MSML_PyExt.vcxproj…
Trying fast lookup…
Found! Configuration name = Debug
Searching for active configuration for MSML_PyExt\MSML_PyExt.vcxproj…
Trying fast lookup…
Found! Configuration name = Debug
Searching for active configuration for MSML_PyExt\MSML_PyExt.vcxproj…
Trying fast lookup…
Found! Configuration name = Debug

Attachments:

You must be logged in to view attached files.

[julienmercenier]

Also, when hitting a breakpoint in C++, the call stack is show without call location.
Clicking on any line leads to  source not available “Frame Not in module”

[support]

Thanks for the log file. It looks like the Python debugging is not working because the variables used by VisualGDB to analyze the Python context got optimized away.

Please follow the instructions in this tutorial to build a modified Python executable that will have the necessary variables available.

[julienmercenier]

Hi,

I’ve yet tried the tutorial to build a modified Python executable without success.

Note that to manage to have a successful build of my extension, i had to modify the python Makefile to add the -fPIC option.

 

Attachments:

You must be logged in to view attached files.

[support]

Sorry, it looks like you are still using the pre-built Python executable instead of the one you built (that should be installed to /usr/local/bin) and it still fails to evaluate the ‘f’ variable that contains the frame info:

gdb --interpreter mi --args "python" "/tmp/com_sysprogs_PythonDebugWrapper.py" "/tmp/com_sysprogs_PythonBreakpointModule.so" /tmp/VisualGDB/c/Local/PRO/DT777/Tests/MSML_PyExt/../Scripts/Test_ApiGeneral.py

Below is the relevant snippet from the log:

-var-create --frame 13 --thread 1 - * "(void *)f"
^done,name="var5",numchild="0",value="0x0",type="void *",thread-id="1",has_more="0"
-data-evaluate-expression --frame 13 --thread 1 "\(void\ \*\)\(\(PyFrameObject\ \*\)0x0\)->f_localsplus\[0]"
^error,msg="Cannot access memory at address 0x178"

Please double-check that you have selected the newly built Python executable in the wizard (see step 11 in the tutorial). If it still doesn’t work, please try using the regular debugging techniques to ensure that the ‘f’ variable is accessible (declaring it volatile should normally work). Without being able to evaluate the frame context, VisualGDB will not be able to decode the state of the Python interpreter.

[julienmercenier]

Hi,

Sorry but I think you did not check the last attatched log file  “VisualGdb-Session-Log-file_After-Python-modified-update.txt” where it shows that I pointed to the expected purposely built Python

gdb --interpreter mi --args "/usr/local/bin/python3.6" "/tmp/com_sysprogs_PythonDebugWrapper.py" "/tmp/com_sysprogs_PythonBreakpointModule.so" /tmp/VisualGDB/c/Local/PRO/DT777/Tests/MSML_PyExt/../Scripts/Test_AcquisitionDelay.py

Julien

 

 

[support]

Sorry about that. Indeed we checked the wrong log file. Based on the latest log, it looks like VisualGDB manages to interpret the Python frames, so the breakpoint problems are caused by something else.

Please try running the following steps in order to pinpoint it:

1. Enable logging in the VisualGDB Diagnostics Console
2. Set one breakpoint in the .py file and another one in your C/C++ module
3. Start debugging and wait for the module breakpoint to hit.
4. Attach the following information:
   1. GDB Session log (similar to the one already attached)
   2. The log from the VisualGDB Diagnostics Console (it should contain details on the Python frame analysis)
   3. The frame list from the Call Stack window when the module breakpoint is hit (simply press Ctrl-A, Ctrl-C to copy it)

This should provide sufficient details for us to see what is going on.

 

[julienmercenier]

You’ll find requested in attach

 

BR,

Julien

Attachments:

You must be logged in to view attached files.

[support]

Thanks for the updated log files, looks like we have found the root cause:

Breakpoint update command: +fTest_AcquisitionDelay.py:199

This line should normally contain the full path to the Python file, e.g.:

Breakpoint update command: +f/tmp/VisualGDB/e/projects/temp/LinuxProject17/main.py:3

Please double-check the path mappings via VisualGDB Project Properties -> Path Mapping. The Windows directory containing the .py file should be mapped to the location on the Linux machine where the file is uploaded. As long as this holds, VisualGDB should be able to set handle the breakpoints fully automatically.

 

[julienmercenier]

Hi,

I’ve tried updating VisualGDB Project Properties -> Path Mapping and this does not change anything.

I still have
<div id=”crayon-5cc2bada24f5e246802850-1″ class=”crayon-line”><span class=”crayon-e”>Breakpoint </span><span class=”crayon-e”>update </span><span class=”crayon-v”>command</span><span class=”crayon-o”>:</span> <span class=”crayon-o”>+</span><span class=”crayon-v”>fTest_AcquisitionDelay</span><span class=”crayon-sy”>.</span><span class=”crayon-v”>py</span><span class=”crayon-o”>:</span><span class=”crayon-cn”>199</span></div>
<div></div>
<div>Note that I double checked my paths (see attached file).</div>
<div></div>
<div>Any other idea ?</div>
 

Attachments:

You must be logged in to view attached files.

[julienmercenier]

sorry for the bad formatting

 

Still have the same breakpiont update command

I double checked the path and they are correct.

[support]

Hi,

It looks like you have an empty entry in the mapping list, that might be interfering with the mapping. Please try removing it and check if the problem persists.

[Author]

Posts