Re: Racy failures on gdb.base/gdbinit-history.exp (native-extended-gdbserver/-m64)

[Patrick Palka <patrick@parcs.ath.cx>]

On Mon, Aug 17, 2015 at 4:10 PM, Patrick Palka <patrick@parcs.ath.cx> wrote:
> On Mon, Aug 17, 2015 at 10:02 AM, Pedro Alves <palves@redhat.com> wrote:
>> On 08/17/2015 02:28 PM, Patrick Palka wrote:
>>
>>> Ah, you already addressed this: a warning is not emitted because
>>> stdout is closed..
>>
>> Yeah.
>>
>>> But because the problem only occurs under extended-gdbserver, I'm
>>> inclined to think the issue is with the testsuite driver, in
>>> particular with the gdb_exit implementation in
>>> lib/gdbserver-support.exp.  One potential issue I notice in this proc
>>> is that when we send "monitor exit" to GDB, we don't necessarily wait
>>> for the command to finish (i.e. for the gdb prompt to get printed).
>>> As soon as the server is observed to get killed, we continue with
>>> exiting.  Dunno if that's substantial..
>>
>> That's very plausible, at least.
>>
>> Maybe that prompt got stuck in the expect buffer, and it confused
>> something else later on?
>>
>> Another theory related to that could be that the new GDB started just
>> while the previous gdb is saving history and has just momentarily
>> renamed the history file to gdbinit-history.gdb_history-gdb-$PID~.
>> But AFAICS, that shouldn't happen because that gdb_exit calls
>> gdbserver_orig_gdb_exit at the end, which only returns after
>> the previous gdb exits...
>>
>> Did anyone ever manage to reproduce this?
>
> Yes, I can reproduce it on x86_64 Debian with dejagnu version 1.5.3.
> But it's pretty rare.  I just do
>
>   while make check RUNTESTFLAGS="gdbinit-history.exp
> --target_board=native-extended-gdbserver --verbose --verbose"; do :;
> done
>
> and wait for a while (20 minutes or so).
>
> But I just locally installed dejagnu from git, and have had the above
> command running for about 30 minutes (after confirming that my local
> copy, not system copy, of dejagnu is being used by the testsuite), and
> fortunately, I could no longer reproduce these FAILs.  So it seems
> that your changes to dejagnu fixed this spurious FAIL as well.  I'll
> let it keep spinning though, just in case.
>
>
>>
>> One thing I'd try is making dejagnu's local_exec (close_wait_program in master)
>> print the result of the "wait -i".  That will show whether gdb exited
>> due to a normal exit, or whether it was killed by SIGTERM or SIGKILL.
>> And then I'd try hacking gdb_safe_append_history to output debug logs
>> to a file instead of stdout (e.g., /tmp/gdb-log).
>>
>> Another would be to add a "show history filename" to the test, to make sure
>> that the gdb that fails to load the previous history actually tried to
>> read the file we expect it to be reading.
>
> Ok, I'll keep these approaches in mind but if I manage to trip over it
> even with dejagnu from git.

Sorry, botched that last sentence there...

Anyway, with dejagnu from git I could no longer reproduce these FAILs
after 3 straight hours of repeatedly running the test.