RFC on the mailing list: http://lists.llvm.org/pipermail/lldb-dev/2018-September/014184.html
Hi Jonas, great you are working on this! I look through and can't say much about the logic. It looks good to me, just added a few notes on minor things.
Not sure if this is relevant here, but in my experience nested classes always caused trouble as there is still no way in C++ to forward declare their names.
This returns a copy by value, while AddProviderToIndex() takes a const ref (that makes sense because ProviderInfo is no sink argument there).
This is the same as Provider &Register(std::unique_ptr<Provider> provider);
Missing brackets, should be assert((!value || !use_reproducer) && "..."); Same below.
I'm having some trouble with the test case. Based on the initialization code I assume I'm not supposed to destroy the SBDebugger singleton shared by the LLDB test suite. If I do it anyway the test crashes with the an exception:
libc++abi.dylib: terminating with uncaught exception of type std::__1::system_error: recursive_mutex lock failed: Invalid argument
Instead I tried to create my own SBDebugger instance and do everything though my_debugger.GetCommandInterpreter().HandleCommand(). But then I don't get a backtrace:
Output Message: * thread #1 * frame #0: 0x0000000100004000 dyld`_dyld_start
While I expect:
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1 * frame #0: 0x0000000100000f48 a.out`foo at main.c:13 frame #1: 0x0000000100000f7b a.out`main(argc=1, argv=0x00007ffeefbff188) at main.c:17 frame #2: 0x00007fff6b9380a1 libdyld.dylib`start + 1 frame #3: 0x00007fff6b9380a1 libdyld.dylib`start + 1
Anybody know what I'm doing wrong here?
Sorry, I can't help with the test. Code looks great! Only a few minor things inline.
Is static_cast<bool>(p) not working?
The default is support to record no history? I think the % operator in NormalizeIndex() will cause UB in that case.
This code existed already, but anyway: it's an overwriting ring buffer right? Maybe that's worth a comment.
First batch of comments, may come back to it today.
5 looks like a magic number, we should give it a name.
It says binary data but it contains a string ... it feels confusing. I can see the underlying methods you are using take char which is annoying since char could be either signed or unsigned so not obvious which u/int8_t make sense.
It is not obvious to me what the underlying assumptions but GetTarget() is locking a weak_ptr don't we have to check and make sure we actually obtain a non empty result? I realize that is not directly here but then why use a weak_ptr if we never verify the return of lock() ?
This pattern appears multiple times in this file. Factor it out into a make / get CStringOrNull() function?
Will it do this on the side or on demand? If it is the former, then "log" seems more appropriate than "generate". If it is the latter, the help text should indicate what triggers the generation.
What about "replay" instead of "reproduce"?
I don't understand that comment. What's that?
if (!size) return;
if (!log) return ...
please invert the condition and early-exit in the error case.
Does this ever return anything else?
These should be before the C++ includes.
Factor this out into a static function?
Thanks a lot for the review feedback everyone!
I don't think that would help a lot:
I just copied the code from somewhere else. However, your link to cppref specifies thread safety for function-local statics, which is not the case here. I don't think that guarantee applies to globals?
I moved this code, but you're totally right, I had to open the header to know what it was.
Added it to the Doxygen comment.
call_once is better for a couple reasons:
Fred, thank you for the comments on general usage.
It is not obvious this is being invoked during global construction ... so I guess that would mean Generator is a global since that seems to be what is calling GetReproducerTempDir?
Maybe a comment explaining the rationale would help prevent someone in the future from coming around and saying hey we can refactor this.
- Introduce command object for reproducers.
- Fix issue where lifetime of the reproducer conflicted with the lifetime of the GDB remote process.
- Ensure packets are properly flushed.
- Reduce complexity in test.
I'm looking at a similar issue that happens during extended lldb testing. I see the following error: "terminating with uncaught exception of type std::__1::system_error: mutex lock failed: Invalid argument "
It happens *very* infrequently, a fraction of a percentage of the time, and only seems to happen on release builds and always when lldb test appears to be exiting. Looks like this:
Ran 1 test in 0.813s
RESULT: PASSED (1 passes, 0 failures, 0 errors, 0 skipped, 0 expected failures, 0 unexpected successes)
terminating with uncaught exception of type std::__1::system_error: mutex lock failed: Invalid argument
This causes the harness to report false failures and there is no clear cut pattern of failure so I can note the tests as flaky and rerun.
Any clue as to what I might look at? I think it might be something in the teardown sequence in Debugger.cpp.