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)
- From: Sergio Durigan Junior <sergiodj at redhat dot com>
- To: Patrick Palka <patrick at parcs dot ath dot cx>
- Cc: "gdb-patches\ at sourceware dot org" <gdb-patches at sourceware dot org>
- Date: Thu, 13 Aug 2015 18:27:55 -0400
- Subject: Re: Racy failures on gdb.base/gdbinit-history.exp (native-extended-gdbserver/-m64)
- 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> <CA+C-WL-Ujsn1ccGNS-wD=RUdbJF1DcGxVYSLU6ubcGThdCQXYg at mail dot gmail dot com>
On Thursday, August 13 2015, Patrick Palka wrote:
> On Thu, Jul 23, 2015 at 2:42 PM, Sergio Durigan Junior
> <email@example.com> wrote:
>> 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.
> Hi Sergio,
> 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
> as well.
Yeah, I still see those FAIL's from time to time:
I may be wrong, but I noticed that the FAIL's happen only on the PPC
GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible