When developing PyTorch, we also run into a lot of mixed Python/C++ language situations. We've recently been experimenting with in-process 'combined' Python/C++/PyTorch 2.0 stack traces to make it easier to understand where code is executing (<a href="https://dev-discuss.pytorch.org/t/fast-combined-c-python-torchscript-inductor-tracebacks/1158" rel="nofollow">https://dev-discuss.pytorch.org/t/fast-combined-c-python-tor...</a>).
GDB can decode Python stack traces as Python code, as long as you have have python-gdb.py from the Python source distribution in the same place as your Python executable.
That reminds me of the time I debugged some code (also neural network) that was in both Java and C++ and I was able to attach both gdb and jdb to the same process but had to disable the segfault trap on gdb because the jvm segfaults all the time in normal operation.
An inspiring, albeit daunting, write-up for someone like me, who has been a python coder for over 10 years, but who has never professionally coded in C or C++. I'd be pleasantly surprised with myself if I could one day debug like that.<p>Also somewhat depressing that, yet again, the GIL was to blame, and that after all that impressive investigatory work, the fix was (spoiler alert!) "rewrite the offending function in C".
It's unfortunate that no one thinks about the debugging experience with anything they build today. It's always a "strap yourself in" experience like in the post.<p>I dream of an IDE that is one-click, full-stack, local debug.<p>I dropped some ideas here: <a href="https://news.ycombinator.com/item?id=35650253" rel="nofollow">https://news.ycombinator.com/item?id=35650253</a>