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