benibenj / vscode-pythonCpp

A Visual Studio Code Debug Extension for debugging mixed Python and C++ code. The extension starts a Python debug session and attaches the C++ debugger to it. This extension is useful for debugging Python programs that call functions from shared libraries (.so/.dll).
Other
47 stars 7 forks source link

Question aboud cuda-gdb extension in attach process #32

Closed will-zzy closed 3 months ago

will-zzy commented 4 months ago

Thanks for your excellent job! This help me a lot! I need some function coded by cuda and I also hope that this extension can work well with cuda extension.

I found that if I use cppdbg and define the miDebuggerPath as /path/to/cuda-gdb in the cpp attach config, I am indeed able to step through CUDA kernel functions and inspect the values of variables within a specific thread. like:

    {
      "name": "Attach",
      "type": "cppdbg",
      "program": "/home/will/anaconda3/bin/python",
      "miDebuggerPath":"/usr/local/cuda-11.6/bin/cuda-gdb",
      "request": "attach",
      "processId": "${command:cuda.pickProcess}",
    },

However, I am unable to jump between threads. I believe this issue is due to not using the cuda-gdb extension as I can jump between threads when I just use cuda-gdb to debug my cpp program. When I change the type from cppdbg to cuda-gdb, the attach process gets blocked on the first line of Python code and stops at /opt/conda/conda-bld/python-split_1654083059479/work/Objects/tupleobject.c. like:

    {
      "name": "Attach",
      "type": "cuda-gdb",

      "program": "/home/will/anaconda3/bin/python",
      "debuggerPath":"/usr/local/cuda-11.6/bin/cuda-gdb",
      "request": "attach",
      "processId": "${command:cuda.pickProcess}",
    },

I tried to modify your plugin, but I know almost nothing about TypeScript. When I attempted to debug the server, I found that the source code does not contain debugAdapter.ts. e.g. line 36. Moreover, when using cppdbg as the debugger for attachment, I can easily implement jumping in my own toy example. However, when the program size increases, for example, diff-gaussian-splatting, during jumping, CUDA often throws an error: "Error: A SIGPIPE has been received, this is likely due to a crash from the CUDA backend."

This is the issue I am currently facing. I wonder if the authors have considered compatibility with cuda-gdb, or if there is anyone with similar needs who has found a solution. Thanks for a lot!

will-zzy commented 3 months ago

I have found a solution for PythonCppDebugger with cuda-gdb, and this is similar to #3 . Determining the path of shared library is indispensable, like:

{
      "name": "Attach",
      "type": "cuda-gdb",
      "program": "/home/will/anaconda3/bin/python",
      "additionalSOLibSearchPath":"/home/will/anaconda3/lib/python3.9/site-packages/myround-1.0-py3.9-linux-x86_64.egg/myround.cpython-39-x86_64-linux-gnu.so",
      "debuggerPath":"/usr/local/cuda-11.6/bin/cuda-gdb",
      "request": "attach",
      "processId": "${command:cuda.pickProcess}",
}

*: Make sure compile in debug mode when using setup.py But another question is raised. This is useful in a toy example, however when I use it to debug gaussian splatting the program often crashes, like: https://github.com/benibenj/vscode-pythonCpp/assets/54033655/7210ad2e-9a73-4e1f-bb1c-c1f5b013a033

But it is exactly useful in a toy example with a simple code logic, like: https://github.com/benibenj/vscode-pythonCpp/assets/54033655/7d757c16-9c7c-4416-9c98-d6a8d5f5fc0b

After consulting with GPT, I believe the main issue arises from the complexity of memory management in Gaussian splatting. Prolonged operation can lead to memory leaks, ultimately causing the program to be terminated.

In the end, I gave up on using PythonCppDebugger for joint debugging of Gaussian splatting, and found using only cpp debugging to be acceptable.