Detailed logging from test runs

Currently we just dump the results of stdout / stderr when running the tests. Occasionally it might be useful for someone diagnosing a failing test to enable more detailed logging. Essentially running a “log enable” command at lldb startup. I see that dotest.py has the ability to pass a runhook via -k, so that one could in theory run dotest.py -k “log enable ”.

Is it worth putting this behind a separate option in dotest.py? Something like this:

dotest.py --enable-logging --log-filters=process|platform|communication

When --enable-logging is specified, the test runner would decide the output file name automatically using the value of the -s option, or if unspecified, the same default that -s uses.

Try using "-t -v" when you need to see extra logging output from the test. Let me know if that isn't enough.

Greg

I’ll look into -v tomorrow, not sure what it does. -t definitely isnt enough though. I basically want all calls to LLDB’s logging statements to be output to a file somewhere when i run the test suite.

The reason this is useful is because i had a race condition that was happening sporadically on different tests when run from the test runner, but never individually. Attaching after the crash wasn’t enough to figure out what caused the error, since the crash was a symptom of something that had happened earlier. So i wanted to see a full log for the crash run

Any solution for this would be best added as arguments to the detest.py. Maybe something like:

--pre-test-commands "log enable -f /tmp/%s-log.txt lldb process"

--post-test-commands "log disable lldb"

And if the commands contain "%s", we replace that with the test name or test number?

We can't really come up with a good default for what to log, so it should be configurable like the above example. I might know that debug info is borked and want to do "log enable dwarf info" or it might be GDB remote is hosed up "log enable gdb-remote packets", or something else. These would allow a log statement to be run before each test (probably best done in the lldbtest.py function Base.setup(self) and Base.tearDown(self)).

Greg