This is an archive of the discontinued LLVM Phabricator instance.

[lldb/Core] Fix finite progress event reporting
ClosedPublic

Authored by mib on Jun 28 2022, 3:31 PM.

Details

Summary

This patch should fix event handling for finite progress reports.

Previously, the event handler would get stuck when receiving a finite
progress report, and stop displaying upcoming reports.
This was due to the fact that we were checking if the progress event was
completed by calling GetCompleted but returns the completion amount
instead of saying whether it's completed.

That caused the current event id to remain the same, preventing all the
following progress reports to be shown to the user.

This patch also adds some logging to facilitate debugging progress events.

rdar://91788326

Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>

Diff Detail

Event Timeline

mib created this revision.Jun 28 2022, 3:31 PM
Herald added a project: Restricted Project. · View Herald TranscriptJun 28 2022, 3:31 PM
mib requested review of this revision.Jun 28 2022, 3:31 PM

The fix looks good but I'm torn about the added logging. On the one hand it'll make finding issues like this easier in the future, but on the other hand, while this code isn't "hot", it is something where performance matters. My concern is that this will potentially cause progress events to get queued. If the progress updates aren't real time they are pretty much useless.

If it were up to me I'd probably remove the logging altogether, but maybe there's a middle ground where we have one log message that we only print in verbose mode? Then the (default) penalty is just checking if the log is enabled and verbose.

What do you think?

mib added a comment.Jun 29 2022, 10:54 AM

The fix looks good but I'm torn about the added logging. On the one hand it'll make finding issues like this easier in the future, but on the other hand, while this code isn't "hot", it is something where performance matters. My concern is that this will potentially cause progress events to get queued. If the progress updates aren't real time they are pretty much useless.

If it were up to me I'd probably remove the logging altogether, but maybe there's a middle ground where we have one log message that we only print in verbose mode? Then the (default) penalty is just checking if the log is enabled and verbose.

What do you think?

Sounds good to me

mib updated this revision to Diff 441110.Jun 29 2022, 11:44 AM

Log only when verbose mode is enabled

JDevlieghere added inline comments.Jun 29 2022, 1:55 PM
lldb/source/Core/Debugger.cpp
1845–1861

What's m_uid?

I would either fold these two log statements into one, and use LLDB_LOGV(GetLog(LLDBLog::Events), ... or I would use the event's dump method:

if (log && log->GetVerbose()) {
  StreamString log_stream;
  log_stream << "Debugger::HandleProgressEvent" ... 
  data->dump(log_stream);
  log->PutString(log_stream.GetString());
}
mib marked an inline comment as done.Jun 29 2022, 3:58 PM
mib added inline comments.
lldb/source/Core/Debugger.cpp
1845–1861

Since some progress events can be broadcasted to a specific debugger instance, m_uid tells use which debugger id is handling this

mib updated this revision to Diff 441195.Jun 29 2022, 4:04 PM
mib marked an inline comment as done.

Refactor logging code

JDevlieghere added inline comments.Jul 5 2022, 9:53 AM
lldb/source/Core/Debugger.cpp
1840–1841

We should still reset the m_current_event_id here, otherwise we can get out of sync if someone changes the value of GetShowProgress.

mib updated this revision to Diff 442397.Jul 5 2022, 2:16 PM
mib marked an inline comment as done.

Address @JDevlieghere comment

This revision is now accepted and ready to land.Jul 5 2022, 2:50 PM
mib edited the summary of this revision. (Show Details)Jul 5 2022, 4:24 PM
This revision was automatically updated to reflect the committed changes.