This is an archive of the discontinued LLVM Phabricator instance.

[LLDB] Clean up after command fails
ClosedPublic

Authored by zequanwu on Aug 22 2022, 10:30 AM.

Details

Summary

CommandObject::CheckRequirements() requires m_exe_ctx being cleaned up.

Diff Detail

Event Timeline

zequanwu created this revision.Aug 22 2022, 10:30 AM
Herald added a project: Restricted Project. · View Herald TranscriptAug 22 2022, 10:30 AM
zequanwu requested review of this revision.Aug 22 2022, 10:30 AM
Herald added a project: Restricted Project. · View Herald TranscriptAug 22 2022, 10:30 AM

I'm not really familiar this code, but could something like llvm::make_scope_exit be useful here?
Also, what is the effect of not calling Cleanup? That subsequent commands fail in some way? Could we make a test case for that?

Each new command invocation is expected to prime the ExecutionContext before invoking the command. I don't think there's any situation where one command should use a previous command's execution context on purpose. So if we're getting to Execute without the CommandInterpreter having proactively set the ExecutionContext for that invocation, that is a bug that should be fixed. This change will make sure that the incorrectly inherited ExecutionContext is empty, but that still means the command is somehow getting invoked with the wrong execution context.

jingham accepted this revision.Aug 24 2022, 10:18 AM

Actually, I think this is 100% correct, and corrects an error I made when I added argument number checking a little while back.

The comments on CheckRequirements say:

Every command should call

// CommandObject::Cleanup() after it has completed.

The early exit in the error case bypassed the call to cleanup that the command was required to do. The m_exe_ctx is probably the less important part of the cleanup that gets missed. If you called a command that has eCommandTryTargetAPILock set in its requirements, but passed it the wrong number of arguments, then we would error out here w/o releasing the m_api_lock, and then if the next command was also a CommandObjectParsed command and required the API lock, it would deadlock. You could probably even write a test that would show this deadlock.

This revision is now accepted and ready to land.Aug 24 2022, 10:18 AM
zequanwu updated this revision to Diff 455311.Aug 24 2022, 11:42 AM

Add a test case.

This revision was automatically updated to reflect the committed changes.