Open breathe opened 1 month ago
From what I've been able to tell there's no support for the equivalent of 'break on exception' in CodeLLDB.
It should be right there:
Make sure you've set "sourceLanguages": ["cpp"]
in your launch config. Or, rather, that you haven't reset it somewhere, because cpp
is the default.
OS:
macOS 14.6.1 (23G93)
VSCode version:CodeLLDB version:
v1.10.0
Compiler:Debuggee: I'm debugging a c++ extension module for python. The module uses nanobind to integrate with the python api. The process entrypoint is the python interpreter. I attach lldb to the process just for debugging code defined within the c++ extension module.
Problem Overview
From what I've been able to tell there's no support for the equivalent of 'break on exception' in CodeLLDB. To work around that I've been adding to my .lldbinit to configure this behavior by adding for example
breakpoint set -E c++
to my .lldbinit file.These breakpoints get hit and pause execution in vscode as expected -- however I've noticed two issues whenever the program execution has been halted due to an exception.
Problem 1
First off -- the 'excluded callers' feature doesn't work when in this mode. I can't right-click on any of the elements of the callstack to ignore the breakpoint -- when I right click on a frame and choose 'Exclude caller' nothing happens -- nothing gets added to Excluded Callers and no errors are added to the LLDB output logs...
To work around that -- I've augmented my .lldbinit with a bit of python scripting -- so my lldb init looks like this
with
lldb_stop_on_cpp_exceptions.py
like this:This configures lldb to stop on cpp exceptions. Each time a cpp exception is thrown, lldb first runs the stop_on_exception script above to decide whether to pause on it. I then try to emulate the 'exclude callers' mechanism with the
function_call_patterns_to_skip
list that I can edit as I need. This appears to work in the sense that I don't stop on exceptions which have frames that match one of the skip patterns but do stop on exceptions that don't.But it would be nicer if could somehow just configure this via the Excluded Callers mechanism.
Problem 2
Normally when I'm paused at a breakpoint in vscode, I can click on frames within the call stack and then examine variables accessible at that scope in the debug console.
When stopped at an exception breakpoint however something works incorrectly. I can click on a frame and then attempt to examine variables from that frame -- however the values printed always appear to be some manner of empty default (NaN for doubles, the empty vector for Eigen::Vector instances ...) -- I actually don't know how to characterize the way the values are wrong -- but local variables defined in functions are accessible for printing in the debug console when I click on the frame -- but then they print incorrectly ...
If I instead use lldb's
frame select <frame_num>
command within the debug console to navigate up the stack to the frame I want to examine -- then I can print things and they print out normally ...Try and illustrate -- here's an image showing me paused at an exception and then clicking up the stack one frame
code-lldb takes me to the correct frame
In debug console I enter
But that output doesn't make any sense because initial_guess was just initialized to be length 5 and all zeros and nothing changed it.
If I issue
frame select 1
and then print again I see the correct/expected value ...(I'm not super well versed in lldb scripting -- but hopefully this is enough information to get the idea)