[lldb] Supporting interrupting a scripted command (e.g. python)

[ashgti]

While looking into how we can support interrupting a command in lldb-dap I noticed that I think we cannot interrupt a script command from the SB API.

Looking at the ScriptInterpreterPythonImpl::Interrupt() function that tries to interrupt running python

llvm-project/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPythonImpl.h

Line 37 in 9ed772c

bool Interrupt() override;

This is only ever triggered from

llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp

Line 3327 in 9ed772c

if (script_interpreter->Interrupt())

Which is only triggered ever called from the IOHandlerEditline or IOHandlerCursesGUI.

I noticed this while implementing tests for the lldb-dap cancel request and using an evaluate request with a command like:

script import time; time.sleep(10); print("Done")

Would always sleep for 10 seconds, even if I triggered SBDebugger::RequestInterrupt() or SBCommandInterpreter::InterruptCommand().

[llvmbot]

@llvm/issue-subscribers-lldb

Author: John Harrison (ashgti)

While looking into how we can support interrupting a command in lldb-dap I noticed that I **think** we cannot interrupt a script command from the SB API.

Looking at the ScriptInterpreterPythonImpl::Interrupt() function that tries to interrupt running python

llvm-project/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPythonImpl.h

Line 37 in 9ed772c

bool Interrupt() override;

This is only ever triggered from

llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp

Line 3327 in 9ed772c

if (script_interpreter->Interrupt())

Which is only triggered ever called from the IOHandlerEditline or IOHandlerCursesGUI.

As far as I can tell, if you try SBDebugger::RequestInterrupt() or SBCommandInterpreter::InterruptCommand() it never tries to interrupt a running python script (e.g. if you have a script do script import time; time.sleep(10);).

[llvmbot]

@llvm/issue-subscribers-lldb-dap

Author: John Harrison (ashgti)

While looking into how we can support interrupting a command in lldb-dap I noticed that I **think** we cannot interrupt a script command from the SB API.

Looking at the ScriptInterpreterPythonImpl::Interrupt() function that tries to interrupt running python

llvm-project/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPythonImpl.h

Line 37 in 9ed772c

bool Interrupt() override;

This is only ever triggered from

llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp

Line 3327 in 9ed772c

if (script_interpreter->Interrupt())

Which is only triggered ever called from the IOHandlerEditline or IOHandlerCursesGUI.

As far as I can tell, if you try SBDebugger::RequestInterrupt() or SBCommandInterpreter::InterruptCommand() it never tries to interrupt a running python script (e.g. if you have a script do script import time; time.sleep(10);).

[ashgti]

cc @JDevlieghere @labath

[labath]

Interrupting python scripts seems like a good idea to me (and I think it already works with ^C aka SBDebugger::DispatchInputInterrupt). I'm not sure what it would take to make it work with this mechanism.

[ashgti]

I guess I'm not sure which API I should use for cancelling, I didn't realize there were all these different APIs for interrupts:

• SBDebugger::DispatchInputInterrupt
• SBDebugger::RequestInterrupt
• SBCommandInterpreter::InterruptCommand

I did see

llvm-project/lldb/include/lldb/Core/Debugger.h

Lines 384 to 402 in b231f6f

	/// Interruption in LLDB:
	///
	/// This is a voluntary interruption mechanism, not preemptive. Parts of lldb
	/// that do work that can be safely interrupted call
	/// Debugger::InterruptRequested and if that returns true, they should return
	/// at a safe point, shortcutting the rest of the work they were to do.
	///
	/// lldb clients can both offer a CommandInterpreter (through
	/// RunCommandInterpreter) and use the SB API's for their own purposes, so it
	/// is convenient to separate "interrupting the CommandInterpreter execution"
	/// and interrupting the work it is doing with the SB API's. So there are two
	/// ways to cause an interrupt:
	/// * CommandInterpreter::InterruptCommand: Interrupts the command currently
	/// running in the command interpreter IOHandler thread
	/// * Debugger::RequestInterrupt: Interrupts are active on anything but the
	/// CommandInterpreter thread till CancelInterruptRequest is called.
	///
	/// Since the two checks are mutually exclusive, however, it's also convenient
	/// to have just one function to check the interrupt state.

but it didn't mention the DispatchInputInterrupt.

[jimingham]

The current RequestInterrupt mechanism is cooperative, if you have a long-running task, you're supposed to check "InterruptRequested" and if it returns true, get out of what you were doing. A "well written" Python based command that does something long-running should check this API periodically and stops what it was doing if the flag was raised. It would certainly be worthwhile to call this.

If your intention is to ask the current command to interrupt itself, then use InterruptCommand, that will try to just interrupt the current command execution.

However, there isn't always a command running. For instance, in asynchronous mode, continue returns when the process is successfully running, and then there isn't an active command. Similarly you could be just running using the SB API's with no commands. To handle those cases, you use SBDebugger::RequestInterrupt.

DispatchInputInterrupt is not really an intrinsic part of the cooperative interrupt mechanism. That's to deal with the the fact that in some environments the actor controlling lldb only has a terminal interface to the debugger, so while a command is running they have no way to issue an interrupt. We do the normal unix thing and bind ^C to DispatchInputInterrupt, and that tells the current IOHandler to do whatever cancellation means for it.

For the normal lldb command IOHandler, we implement ^C in a slightly more complicated way. I wanted to give commands a chance to interrupt on their own terms using the cooperative InterruptRequested machinery, but then also have a way to say "really quit" if that was a thing they could do. So the first ^C sends InterruptCommand. If there's no command running then we immediately do DispatchInputInterrupt. If there is a command running but that doesn't cause a command to say it's interrupted itself, then the next ^C becomes a "DispatchInputInterrupt".

That's why, for instance, if you are in sync mode and had run the "continue" command (which currently doesn't check the interrupt flag) you have to hit two ^C's to stop the process or interrupt a python script based command with a KeyboardInterrupt.

[jimingham]

We could make all the synchronous versions of the execution control commands work more naturally if they did a timed WaitForProcessToStop rather than a blocking wait, and check the interrupt flag when they wake up, and interrupt the process directly.

When I did this bit of work I had the time to get the framework in place and use it in some places (like looking for remote symbol files) that would really benefit from cancellation. But it's still a project to go through all the other commands and see if they should/could also cooperate in this interruption.

[ashgti]

For reference #130169 is my PR for cancelling lldb-dap requests