This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH v4] Enable 'set print inferior-events' and improve detach/fork/kill/exit messages


On Friday, April 06 2018, Pedro Alves wrote:

> On 04/06/2018 04:56 PM, Sergio Durigan Junior wrote:
>
>>> I'm not sure I understand the need for this.  If you left this
>>> gdb_test_multiple exactly as it was before your patch, wouldn't it all
>>> work the same?
>> 
>> As I said in the other message, the problem here is that
>> ${inf_output_re} can happen between the two messages.  For example:
>> 
>>   Detaching from program: .../gdb/testsuite/outputs/gdb.threads/process-dies-while-detaching/process-dies-while-detaching-1-detach, process 7440
>>   exited, status=0
>>   [Inferior 1 (process 7440) detached]
>> 
>> In this case, leave gdb_test_multiple as it was before doesn't catch
>> this case, which leads to a racy failure.  
>
> I'm not sure I get it -- why does it need to catch it?
>
> The original gdb_test_multiple matches the first line:
>
> "Detaching from program: .../gdb/testsuite/outputs/gdb.threads/process-dies-while-detaching/process-dies-while-detaching-1-detach, process 7440"
>
> and stops here, there's no $gdb_prompt anchor.  And then, the loop below
> should consume both the inferior output and the gdb prompt.
>
> My question is then, why do you need to expect the
>  "[Inferior 1 (process 7440) detached]"
> part in this test at all?

Thanks for the message.

I guess I was confusing things, then.  I updated all regexps to expect
the "[Inferior ... detached]" message after the "Detaching ...", because
that's what GDB will print.  But in this specific case, as you noticed,
it's not necessary.  I reverted the testcase back to its original form,
and am running a loop to make sure there's no racy test, but I think
it should be enough to just it as is.

>> However, I noticed that my
>> patch also doesn't fix the failure (I thought it did, but then I saw it
>> happening again on the BuildBot).  That's another reason why I
>> "cancelled" this version of the patch.
>
> Also please try these racy issues with "make check-read1".

I did this, and found no racy issues.

I'll run another full regression test on BuildBot, and resubmit the
patch.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]