Ah yes, our old friend TestHelloWorld. This guy definitely needs to be
fixed. I haven't actually looked at the code before to see why it was
so flaky, but now it all makes sense....
I would just use the "usual" protocol of "expr release_child = 1"
here, but if you wanna go crazy, then go ahead... :)
On 27 August 2015 at 16:12, Zachary Turner <ztur...@google.com> wrote:
> It's not that it relies on a specific thread being selected, because as you
> can see there are 2 threads in that trace. The problem is that the second
> frame is not even yet in the main function, it's in the startup code because
> of how early the attach process happens (which itsels is probably actually
> racy, since attach is user-initiated and might happen before or after main
> function has entered. But the test checks for main.c as the source file of
> the second frame, so this si where the probelm lies.
>
> On Thu, Aug 27, 2015 at 1:41 AM Pavel Labath <lab...@google.com> wrote:
>>
>> The main issue I see with all these APIs is that they are
>> non-blocking. That is, the test executable cannot simply say "wait
>> until a debugger attaches", but it will have to do something like:
>> while (! attached) {
>> sleep(X);
>> attached =
>> figure_out_if_i_am_attached_using_architecture_specific_methods();
>> }
>>
>> This does not sound to me like it will be significantly more stable
>> then the currently used method:
>> while (! attached) sleep(X);
>> where the debugger flips the variable after it attaches.
>>
>> However, I would definitely welcome providing a default implementation
>> of wait_for_debugger_attach() (regardless of how it is implemented),
>> which all tests can use, instead of each one rolling out its own.
>>
>>
>> Another possible implementation would be to use some standard IPC
>> mechanism (pipes, signals, sockets, ...) for waking up the inferior
>> once the debugger is ready. The test inferior could e.g., wait on a
>> pipe and the debugger will write a single byte there once it attaches.
>> Since we control both the test runner and the test inferior, this is
>> enough and you don't need any fancy APIs. The tricky part here would
>> be to make sure this works during remote debugging.
>>
>>
>> That said, I don't think the current issues with the attach tests are
>> caused by this problem. The current protocol, however awkard it may
>> be, should still work IMO, but we are still seeing flakyness in all
>> tests that do attaches. I think we have some other issues here and I
>> am suspecting races in other parts of the system. I was planning to
>> take a look at these soon...
>>
>>
>> > LLDB picks this up, and the result is that LLDB stops and waits for the
>> > user
>> > to continue the inferior just as it would with any other breakpoint, and
>> > if
>> > you were to get a backtrace you might see something like this:
>> >
>> > looking at: Stack traces for SBProcess: pid = 12588, state = stopped,
>> > threads = 2, executable =
>> > test_with_dwarf_and_attach_to_process_with_id_api
>> > Stack trace for thread id=0x3428 name=None queue=None stop reason=none
>> > frame #0: 0xffffffffffffffff ntdll.dll`DbgBreakPoint + 1
>>
>> This sounds like a pretty strange way to stop the inferior (I was
>> quite surprised that ^C also injects a thread into a program), however
>> it is fundamentally equivalent to what the other platforms do. When we
>> attach on Linux, the inferior also comes out stopped. The difference
>> is that we get a SIGSTOP as a stop reason, while on windows you get a
>> breakpoint in a different thread. It sounds to me like the tests
>> should not rely on a specific thread being selected after the attach.
>> Most tests don't do backtraces right after attach since you're likely
>> to get very unpredictable results on any platform. Those that do
>> should be fixed to set a breakpoint on the place that interests them,
>> resume and do a backtrace once they hit that breakpoint. I vaguelly
>> recall some tests that actually do try to backtrace on attach on
>> purpose (for example, to see if you can backtrace out of a syscall).
>> If they exist, we should fix them to first select the right thread for
>> the backtracing, so they don't try to use the DbgBreakPoint thread.
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
