Mixing
Calling StepOut() and EvaluateExpression() in immediate sequence
Calling StepOut() and then EvaluateExpression() in immediate sequence, for example from a script, does not return the expected value.
It does work when manually and separately calling these functions from the console:
(lldb) script lldb.thread.StepOut()
(lldb) script print lldb.frame.EvaluateExpression("$rax").description
However, it does not work when combining them into one statement:
(lldb) script lldb.thread.StepOut(); print lldb.frame.EvaluateExpression("$rax").description
This prints None to the console.
Checking the process's state shows that there's a difference between the two forms:
(lldb) script lldb.thread.StepOut()
(lldb) script print lldb.process.state
The state value is lldb.eStateStopped.
When running in sequence, the state immediately after StepOut is different:
(lldb) script lldb.thread.StepOut(); print lldb.process.state
Here the state is lldb.eStateRunning.
So the questions is:
How should code be written to ensure StepOut has fully completed? I'm assuming that requires the state to be back to stopped, and the frame to be initialized/setup, before calls to EvaluateExpression()?
lldb
asked Jan 3 at 1:25
Dave LeeDave Lee
4,8472732
add a comment |
Calling StepOut() and then EvaluateExpression() in immediate sequence, for example from a script, does not return the expected value.
It does work when manually and separately calling these functions from the console:
(lldb) script lldb.thread.StepOut()
(lldb) script print lldb.frame.EvaluateExpression("$rax").description
However, it does not work when combining them into one statement:
(lldb) script lldb.thread.StepOut(); print lldb.frame.EvaluateExpression("$rax").description
This prints None to the console.
Checking the process's state shows that there's a difference between the two forms:
(lldb) script lldb.thread.StepOut()
(lldb) script print lldb.process.state
The state value is lldb.eStateStopped.
When running in sequence, the state immediately after StepOut is different:
(lldb) script lldb.thread.StepOut(); print lldb.process.state
Here the state is lldb.eStateRunning.
So the questions is:
How should code be written to ensure StepOut has fully completed? I'm assuming that requires the state to be back to stopped, and the frame to be initialized/setup, before calls to EvaluateExpression()?
lldb
asked Jan 3 at 1:25
Dave LeeDave Lee
4,8472732
add a comment |
Calling StepOut() and then EvaluateExpression() in immediate sequence, for example from a script, does not return the expected value.
It does work when manually and separately calling these functions from the console:
(lldb) script lldb.thread.StepOut()
(lldb) script print lldb.frame.EvaluateExpression("$rax").description
However, it does not work when combining them into one statement:
(lldb) script lldb.thread.StepOut(); print lldb.frame.EvaluateExpression("$rax").description
This prints None to the console.
Checking the process's state shows that there's a difference between the two forms:
(lldb) script lldb.thread.StepOut()
(lldb) script print lldb.process.state
The state value is lldb.eStateStopped.
When running in sequence, the state immediately after StepOut is different:
(lldb) script lldb.thread.StepOut(); print lldb.process.state
Here the state is lldb.eStateRunning.
So the questions is:
How should code be written to ensure StepOut has fully completed? I'm assuming that requires the state to be back to stopped, and the frame to be initialized/setup, before calls to EvaluateExpression()?
lldb
asked Jan 3 at 1:25
Dave LeeDave Lee
4,8472732
Calling StepOut() and then EvaluateExpression() in immediate sequence, for example from a script, does not return the expected value.
It does work when manually and separately calling these functions from the console:
(lldb) script lldb.thread.StepOut()
(lldb) script print lldb.frame.EvaluateExpression("$rax").description
However, it does not work when combining them into one statement:
(lldb) script lldb.thread.StepOut(); print lldb.frame.EvaluateExpression("$rax").description
This prints None to the console.
Checking the process's state shows that there's a difference between the two forms:
(lldb) script lldb.thread.StepOut()
(lldb) script print lldb.process.state
The state value is lldb.eStateStopped.
When running in sequence, the state immediately after StepOut is different:
(lldb) script lldb.thread.StepOut(); print lldb.process.state
Here the state is lldb.eStateRunning.
So the questions is:
How should code be written to ensure StepOut has fully completed? I'm assuming that requires the state to be back to stopped, and the frame to be initialized/setup, before calls to EvaluateExpression()?
lldb
lldb
asked Jan 3 at 1:25
Dave LeeDave Lee
4,8472732
asked Jan 3 at 1:25
Dave LeeDave Lee
4,8472732
asked Jan 3 at 1:25
Dave LeeDave Lee
4,8472732
asked Jan 3 at 1:25
Dave LeeDave Lee
4,8472732
asked Jan 3 at 1:25
Dave LeeDave Lee
4,8472732
4,8472732
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
The lldb SBDebugger can run in either synchronous or asynchronous mode.
In async mode, the commands that cause the debugee to run return as soon as it starts running. That's useful if you are planning control the whole debug session, handling events yourself, etc. There's an example of doing that here:
http://llvm.org/svn/llvm-project/lldb/trunk/examples/python/process_events.py
In synchronous mode, StepOut won't return till the debugee stops again. That mode is more convenient for one-off commands like the ones you show.
You can set the mode on the debugee using the "SBDebugger.SetAsync" call, passing True for async, and False for sync.
answered Jan 3 at 3:17
Jim InghamJim Ingham
14.4k13035
I should have mentioned async. If I callSetAsync(False)beforeStepOut(), then lldb (client) is put into an unusable state. Specifically, the thread does not appear to step-out, it's unclear what happens, Xcode and the console provide no feedback of changes. In addition, afterSetAsync(False), the next command run, even justhelp, hangs indefinitely. I thought async property only applied toContinue(), so I didn't think it was relevant toStepOut().
– Dave Lee
Jan 3 at 5:08
I have a solution that uses a scripted thread plan. However I hit issues there too. I can get thesummaryof the SBValue, but callingGetObjectDescription()causes lldb to hang.
– Dave Lee
Jan 3 at 19:26
Did you make sure to set it back to true when you were done? Xcode will not be very happy in Sync mode. Whenever I do this in python code I always call GetAsync first, set it to false, then set it back to whatever GetAsync returned on the way out.
– Jim Ingham
Jan 17 at 18:39
Yep, I tried it both ways. You can see Xcode's disjoint debugging behavior by running a one linerscript. Here's an example gist.github.com/kastiglione/ea2a26fbc1470c08e1e64d534f614bd8
– Dave Lee
Jan 17 at 18:51
So there is a bug when lldb is embedded in Xcode where if you run a python based command in a breakpoint callback (or stop-hook), Xcode will stall. If you are using it this way, for now you will have to put the code in a Python breakpoint callback, and add that to the breakpoint. You can't at present use the Xcode Breakpoint UI features - it doesn't support adding Python callbacks. So the down-side of this workaround is you will have to make these breakpoints and add the command to them by hand, either in the lldb console or in a command file you source.
– Jim Ingham
Jan 17 at 20:52
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f54015238%2fcalling-stepout-and-evaluateexpression-in-immediate-sequence%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
The lldb SBDebugger can run in either synchronous or asynchronous mode.
In async mode, the commands that cause the debugee to run return as soon as it starts running. That's useful if you are planning control the whole debug session, handling events yourself, etc. There's an example of doing that here:
http://llvm.org/svn/llvm-project/lldb/trunk/examples/python/process_events.py
In synchronous mode, StepOut won't return till the debugee stops again. That mode is more convenient for one-off commands like the ones you show.
You can set the mode on the debugee using the "SBDebugger.SetAsync" call, passing True for async, and False for sync.
answered Jan 3 at 3:17
Jim InghamJim Ingham
14.4k13035
I should have mentioned async. If I callSetAsync(False)beforeStepOut(), then lldb (client) is put into an unusable state. Specifically, the thread does not appear to step-out, it's unclear what happens, Xcode and the console provide no feedback of changes. In addition, afterSetAsync(False), the next command run, even justhelp, hangs indefinitely. I thought async property only applied toContinue(), so I didn't think it was relevant toStepOut().
– Dave Lee
Jan 3 at 5:08
I have a solution that uses a scripted thread plan. However I hit issues there too. I can get thesummaryof the SBValue, but callingGetObjectDescription()causes lldb to hang.
– Dave Lee
Jan 3 at 19:26
Did you make sure to set it back to true when you were done? Xcode will not be very happy in Sync mode. Whenever I do this in python code I always call GetAsync first, set it to false, then set it back to whatever GetAsync returned on the way out.
– Jim Ingham
Jan 17 at 18:39
Yep, I tried it both ways. You can see Xcode's disjoint debugging behavior by running a one linerscript. Here's an example gist.github.com/kastiglione/ea2a26fbc1470c08e1e64d534f614bd8
– Dave Lee
Jan 17 at 18:51
So there is a bug when lldb is embedded in Xcode where if you run a python based command in a breakpoint callback (or stop-hook), Xcode will stall. If you are using it this way, for now you will have to put the code in a Python breakpoint callback, and add that to the breakpoint. You can't at present use the Xcode Breakpoint UI features - it doesn't support adding Python callbacks. So the down-side of this workaround is you will have to make these breakpoints and add the command to them by hand, either in the lldb console or in a command file you source.
– Jim Ingham
Jan 17 at 20:52
add a comment |
The lldb SBDebugger can run in either synchronous or asynchronous mode.
In async mode, the commands that cause the debugee to run return as soon as it starts running. That's useful if you are planning control the whole debug session, handling events yourself, etc. There's an example of doing that here:
http://llvm.org/svn/llvm-project/lldb/trunk/examples/python/process_events.py
In synchronous mode, StepOut won't return till the debugee stops again. That mode is more convenient for one-off commands like the ones you show.
You can set the mode on the debugee using the "SBDebugger.SetAsync" call, passing True for async, and False for sync.
answered Jan 3 at 3:17
Jim InghamJim Ingham
14.4k13035
I should have mentioned async. If I callSetAsync(False)beforeStepOut(), then lldb (client) is put into an unusable state. Specifically, the thread does not appear to step-out, it's unclear what happens, Xcode and the console provide no feedback of changes. In addition, afterSetAsync(False), the next command run, even justhelp, hangs indefinitely. I thought async property only applied toContinue(), so I didn't think it was relevant toStepOut().
– Dave Lee
Jan 3 at 5:08
I have a solution that uses a scripted thread plan. However I hit issues there too. I can get thesummaryof the SBValue, but callingGetObjectDescription()causes lldb to hang.
– Dave Lee
Jan 3 at 19:26
Did you make sure to set it back to true when you were done? Xcode will not be very happy in Sync mode. Whenever I do this in python code I always call GetAsync first, set it to false, then set it back to whatever GetAsync returned on the way out.
– Jim Ingham
Jan 17 at 18:39
Yep, I tried it both ways. You can see Xcode's disjoint debugging behavior by running a one linerscript. Here's an example gist.github.com/kastiglione/ea2a26fbc1470c08e1e64d534f614bd8
– Dave Lee
Jan 17 at 18:51
So there is a bug when lldb is embedded in Xcode where if you run a python based command in a breakpoint callback (or stop-hook), Xcode will stall. If you are using it this way, for now you will have to put the code in a Python breakpoint callback, and add that to the breakpoint. You can't at present use the Xcode Breakpoint UI features - it doesn't support adding Python callbacks. So the down-side of this workaround is you will have to make these breakpoints and add the command to them by hand, either in the lldb console or in a command file you source.
– Jim Ingham
Jan 17 at 20:52
add a comment |
The lldb SBDebugger can run in either synchronous or asynchronous mode.
In async mode, the commands that cause the debugee to run return as soon as it starts running. That's useful if you are planning control the whole debug session, handling events yourself, etc. There's an example of doing that here:
http://llvm.org/svn/llvm-project/lldb/trunk/examples/python/process_events.py
In synchronous mode, StepOut won't return till the debugee stops again. That mode is more convenient for one-off commands like the ones you show.
You can set the mode on the debugee using the "SBDebugger.SetAsync" call, passing True for async, and False for sync.
answered Jan 3 at 3:17
Jim InghamJim Ingham
14.4k13035
The lldb SBDebugger can run in either synchronous or asynchronous mode.
In async mode, the commands that cause the debugee to run return as soon as it starts running. That's useful if you are planning control the whole debug session, handling events yourself, etc. There's an example of doing that here:
http://llvm.org/svn/llvm-project/lldb/trunk/examples/python/process_events.py
In synchronous mode, StepOut won't return till the debugee stops again. That mode is more convenient for one-off commands like the ones you show.
You can set the mode on the debugee using the "SBDebugger.SetAsync" call, passing True for async, and False for sync.
answered Jan 3 at 3:17
Jim InghamJim Ingham
14.4k13035
answered Jan 3 at 3:17
Jim InghamJim Ingham
14.4k13035
answered Jan 3 at 3:17
Jim InghamJim Ingham
14.4k13035
answered Jan 3 at 3:17
Jim InghamJim Ingham
14.4k13035
14.4k13035
I should have mentioned async. If I callSetAsync(False)beforeStepOut(), then lldb (client) is put into an unusable state. Specifically, the thread does not appear to step-out, it's unclear what happens, Xcode and the console provide no feedback of changes. In addition, afterSetAsync(False), the next command run, even justhelp, hangs indefinitely. I thought async property only applied toContinue(), so I didn't think it was relevant toStepOut().
– Dave Lee
Jan 3 at 5:08
I have a solution that uses a scripted thread plan. However I hit issues there too. I can get thesummaryof the SBValue, but callingGetObjectDescription()causes lldb to hang.
– Dave Lee
Jan 3 at 19:26
Did you make sure to set it back to true when you were done? Xcode will not be very happy in Sync mode. Whenever I do this in python code I always call GetAsync first, set it to false, then set it back to whatever GetAsync returned on the way out.
– Jim Ingham
Jan 17 at 18:39
Yep, I tried it both ways. You can see Xcode's disjoint debugging behavior by running a one linerscript. Here's an example gist.github.com/kastiglione/ea2a26fbc1470c08e1e64d534f614bd8
– Dave Lee
Jan 17 at 18:51
So there is a bug when lldb is embedded in Xcode where if you run a python based command in a breakpoint callback (or stop-hook), Xcode will stall. If you are using it this way, for now you will have to put the code in a Python breakpoint callback, and add that to the breakpoint. You can't at present use the Xcode Breakpoint UI features - it doesn't support adding Python callbacks. So the down-side of this workaround is you will have to make these breakpoints and add the command to them by hand, either in the lldb console or in a command file you source.
– Jim Ingham
Jan 17 at 20:52
add a comment |
I should have mentioned async. If I callSetAsync(False)beforeStepOut(), then lldb (client) is put into an unusable state. Specifically, the thread does not appear to step-out, it's unclear what happens, Xcode and the console provide no feedback of changes. In addition, afterSetAsync(False), the next command run, even justhelp, hangs indefinitely. I thought async property only applied toContinue(), so I didn't think it was relevant toStepOut().
– Dave Lee
Jan 3 at 5:08
I have a solution that uses a scripted thread plan. However I hit issues there too. I can get thesummaryof the SBValue, but callingGetObjectDescription()causes lldb to hang.
– Dave Lee
Jan 3 at 19:26
Did you make sure to set it back to true when you were done? Xcode will not be very happy in Sync mode. Whenever I do this in python code I always call GetAsync first, set it to false, then set it back to whatever GetAsync returned on the way out.
– Jim Ingham
Jan 17 at 18:39
Yep, I tried it both ways. You can see Xcode's disjoint debugging behavior by running a one linerscript. Here's an example gist.github.com/kastiglione/ea2a26fbc1470c08e1e64d534f614bd8
– Dave Lee
Jan 17 at 18:51
So there is a bug when lldb is embedded in Xcode where if you run a python based command in a breakpoint callback (or stop-hook), Xcode will stall. If you are using it this way, for now you will have to put the code in a Python breakpoint callback, and add that to the breakpoint. You can't at present use the Xcode Breakpoint UI features - it doesn't support adding Python callbacks. So the down-side of this workaround is you will have to make these breakpoints and add the command to them by hand, either in the lldb console or in a command file you source.
– Jim Ingham
Jan 17 at 20:52
I should have mentioned async. If I call
SetAsync(False) before StepOut(), then lldb (client) is put into an unusable state. Specifically, the thread does not appear to step-out, it's unclear what happens, Xcode and the console provide no feedback of changes. In addition, after SetAsync(False), the next command run, even just help, hangs indefinitely. I thought async property only applied to Continue(), so I didn't think it was relevant to StepOut().– Dave Lee
Jan 3 at 5:08
I should have mentioned async. If I call
SetAsync(False) before StepOut(), then lldb (client) is put into an unusable state. Specifically, the thread does not appear to step-out, it's unclear what happens, Xcode and the console provide no feedback of changes. In addition, after SetAsync(False), the next command run, even just help, hangs indefinitely. I thought async property only applied to Continue(), so I didn't think it was relevant to StepOut().– Dave Lee
Jan 3 at 5:08
I have a solution that uses a scripted thread plan. However I hit issues there too. I can get the
summary of the SBValue, but calling GetObjectDescription() causes lldb to hang.– Dave Lee
Jan 3 at 19:26
I have a solution that uses a scripted thread plan. However I hit issues there too. I can get the
summary of the SBValue, but calling GetObjectDescription() causes lldb to hang.– Dave Lee
Jan 3 at 19:26
Did you make sure to set it back to true when you were done? Xcode will not be very happy in Sync mode. Whenever I do this in python code I always call GetAsync first, set it to false, then set it back to whatever GetAsync returned on the way out.
– Jim Ingham
Jan 17 at 18:39
Did you make sure to set it back to true when you were done? Xcode will not be very happy in Sync mode. Whenever I do this in python code I always call GetAsync first, set it to false, then set it back to whatever GetAsync returned on the way out.
– Jim Ingham
Jan 17 at 18:39
Yep, I tried it both ways. You can see Xcode's disjoint debugging behavior by running a one liner
script. Here's an example gist.github.com/kastiglione/ea2a26fbc1470c08e1e64d534f614bd8– Dave Lee
Jan 17 at 18:51
Yep, I tried it both ways. You can see Xcode's disjoint debugging behavior by running a one liner
script. Here's an example gist.github.com/kastiglione/ea2a26fbc1470c08e1e64d534f614bd8– Dave Lee
Jan 17 at 18:51
So there is a bug when lldb is embedded in Xcode where if you run a python based command in a breakpoint callback (or stop-hook), Xcode will stall. If you are using it this way, for now you will have to put the code in a Python breakpoint callback, and add that to the breakpoint. You can't at present use the Xcode Breakpoint UI features - it doesn't support adding Python callbacks. So the down-side of this workaround is you will have to make these breakpoints and add the command to them by hand, either in the lldb console or in a command file you source.
– Jim Ingham
Jan 17 at 20:52
So there is a bug when lldb is embedded in Xcode where if you run a python based command in a breakpoint callback (or stop-hook), Xcode will stall. If you are using it this way, for now you will have to put the code in a Python breakpoint callback, and add that to the breakpoint. You can't at present use the Xcode Breakpoint UI features - it doesn't support adding Python callbacks. So the down-side of this workaround is you will have to make these breakpoints and add the command to them by hand, either in the lldb console or in a command file you source.
– Jim Ingham
Jan 17 at 20:52
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f54015238%2fcalling-stepout-and-evaluateexpression-in-immediate-sequence%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
