Page MenuHomePhabricator

Unify random timeouts throughout LLDB and make them configurable.
ClosedPublic

Authored by aprantl on Apr 5 2019, 2:32 PM.

Details

Summary

Since these timeouts guard against catastrophic error in debugserver, I also increased all of them to the maximum value among them.

The motivation for this test was the observation that an asanified LLDB would often exhibit seemingly random test failures that could be traced back to debugserver packets getting out of sync. With this path applied I can no longer reproduce the one particular failure mode that I was investigating.

rdar://problem/49441261

Diff Detail

Repository
rLLDB LLDB

Event Timeline

aprantl created this revision.Apr 5 2019, 2:32 PM
Herald added a project: Restricted Project. · View Herald TranscriptApr 5 2019, 2:32 PM

I should also note that I did check that process was either checked or dereferenced above the the locations where this patch dereferences it.

aprantl updated this revision to Diff 193975.Apr 5 2019, 2:50 PM

Tweaked the name of the option after some off-line discussion with Jim.

jingham accepted this revision.Apr 5 2019, 3:27 PM

LGTM

This revision is now accepted and ready to land.Apr 5 2019, 3:27 PM
This revision was automatically updated to reflect the committed changes.

The motivation for this test was the observation that an asanified LLDB would often exhibit seemingly random test failures that could be traced back to debugserver packets getting out of sync. With this path applied I can no longer reproduce the one particular failure mode that I was investigating.

I hate that GDB remote packets can get out of sync. We should really think about adding sequence IDs to the GDB remote packets and responses and teach our GDB communication code to correctly deal with these. So many weird problems happen when things get out of sync.