CODEWITHSUNDEEP
lldb
Insaf K
Insaf K

Reputation: 366

Disable LLDB restoring state whenever a function called within debugger is crashed

I'm debugging a C project using LLDB debugger.

I'm attaching the debugger to a program and then calling some functions within the debugger, which are expected to crash. I wanted to know where this function crashes.

The problem is - since the function is called from within the debugger, once the function has crashed the debugger resets the state back to the state before calling the function. I don't want this, any idea how to disable this?

This is the message I get from the lldb debugger

lldb output]

Thanks

Upvotes: 0

Views: 455

Answers (1)

Jim Ingham
Jim Ingham

Reputation: 27118

You can get lldb to preserve the state of a thread when an expression crashes in two ways.

1) If you want to ALWAYS stop in the crashed state when expressions crash, set the setting target.process.unwind-on-error-in-expressions to false:

settings set target.process.unwind-on-error-in-expressions false

either in the command line or in your ~\.lldbinit file.

BTW, for this reason, if you are using the lldb SB API's for scripting or you're writing your own debugger GUI and you need to call a function for some purpose, it's a good idea to explicitly override this setting when calling functions. Use the SBExpressionOptions.SetUnwindOnErrors method for this. Otherwise, your users might end up staring at a crash in an expression they did not call...

2) You can do it on a per-expression basis using:

expr -u 0 -- <expression>

Note, if you do this often, you can make an alias for this. Something like:

command alias pu expr -u 0 --

Then just do:

pu <expression>

While stopped at an expression crash, you can examine the stack, local variables, call other expressions, etc just as you would at a normal stop in lldb. When you are done with this investigation and want to return the thread to the state it was in prior to calling the expression, use the command:

thread return -x

Calling expressions on a thread nests; you can call an expression, stop when it crashes, call another expression that crashes, stop when it crashes, etc... thread return -x will unwind the youngest expression crash.

On a related note, you can also set breakpoints in a function that you call in the expression parser, hit the breakpoint and then step through the rest of the expression evaluation. That is also not on by default, but is controlled by the -i flag to expr like:

expr -i 0 -- <expression>

When you are done examining the code you've called, you can either use thread return -x to wipe the expression evaluation from the thread stack, or you can continue and the expression will finish evaluating and the result will be printed.

This trick is quite handy for watching how functions behave with odd inputs, etc.

Upvotes: 2

Related Questions