This is the mail archive of the
mailing list for the GDB project.
Re: Racy failures on gdb.base/gdbinit-history.exp (native-extended-gdbserver/-m64) (was: Re: [PATCH] Don't truncate the history file when history size is unlimited)
- From: Patrick Palka <patrick at parcs dot ath dot cx>
- To: Sergio Durigan Junior <sergiodj at redhat dot com>
- Cc: "gdb-patches at sourceware dot org" <gdb-patches at sourceware dot org>
- Date: Thu, 13 Aug 2015 11:18:07 -0400
- Subject: Re: Racy failures on gdb.base/gdbinit-history.exp (native-extended-gdbserver/-m64) (was: Re: [PATCH] Don't truncate the history file when history size is unlimited)
- Authentication-results: sourceware.org; auth=none
- References: <1433878062-23560-1-git-send-email-patrick at parcs dot ath dot cx> <1434466413-28892-1-git-send-email-patrick at parcs dot ath dot cx> <87mvym67i5 dot fsf_-_ at redhat dot com>
On Thu, Jul 23, 2015 at 2:42 PM, Sergio Durigan Junior
> On Tuesday, June 16 2015, Patrick Palka wrote:
>> We still do not handle "set history size unlimited" correctly. In
>> particular, after writing to the history file, we truncate the history
>> even if it is unlimited.
>> This patch makes sure that we do not call history_truncate_file() if the
>> history is not stifled (i.e. if it's unlimited). This bug causes the
>> history file to be truncated to zero on exit when one has "set history
>> size unlimited" in their gdbinit file. Although this code exists in GDB
>> 7.8, the bug is masked by a pre-existing bug that's been only fixed in
>> GDB 7.9 (PR gdb/17820).
> Hey Patrick,
> Looking at the BuildBot logs today, I found that this new test is
> failing occasionally on native-extended-gdbserver testing. Take a look
> at the following build:
> You can see that gdb.base/gdbinit-history.exp failed:
> PASS -> FAIL: gdb.base/gdbinit-history.exp: truncation: appending: server show commands
> PASS -> FAIL: gdb.base/gdbinit-history.exp: truncation: creating: server show commands
> The gdb.log is here:
> I haven't really investigated to determine what's going on here, but let
> me know if you need any help with this.
Have you seen these spurious FAILs pop up recently? I wonder if the
fixes to SIGTERM handling I made a few weeks ago may have fixed this