From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31112 invoked by alias); 23 Jul 2015 19:33:45 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 30389 invoked by uid 89); 23 Jul 2015 19:33:45 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 X-HELO: mail-oi0-f45.google.com Received: from mail-oi0-f45.google.com (HELO mail-oi0-f45.google.com) (209.85.218.45) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Thu, 23 Jul 2015 19:33:42 +0000 Received: by oige126 with SMTP id e126so3557033oig.0 for ; Thu, 23 Jul 2015 12:33:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=LWN1F+MlICvgisE+JAWySS2WqVWSsvaa3XYGAuLPm9M=; b=JSYOwkJqb3HkThEj6/tnxSFTI3MukD5gXqYhiwQXJ09w5lvve/kzA5dJScvfUZzjra UlVpaX0VYlEhmUmCEu496pfqvB3ElFMHLTQxVL0X/ipfZXuIk5sQHW8k52NsUuO6LLYl /aXYBzxUpO5ISAV4KjXO40+Ds/wbvLNGmE9kcjzoiUnGANMy4I1RziqaGuT69uPwlQjG OzFkLKsC62JLEelg/fCy9c4og2zgmXWFTQvP5p8XMmuyHtOmg+WW7diHHRmzgCwTjzGj vmohT1XIMEqcdWZvxQF+rm2Ej3NQk+fgVxvjA2KXfDFUcuio4GQtm45WZToSP7dW6zwI C7FA== X-Gm-Message-State: ALoCoQm440LLh3DFOb/LH4yuM2Kyko+aCxCLi44aOYNUYrU4UqTgE7ML5a0w3gJFUvKiANnXd53D X-Received: by 10.202.58.215 with SMTP id h206mr10621143oia.23.1437680019884; Thu, 23 Jul 2015 12:33:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.56.202 with HTTP; Thu, 23 Jul 2015 12:33:20 -0700 (PDT) In-Reply-To: <87mvym67i5.fsf_-_@redhat.com> References: <1433878062-23560-1-git-send-email-patrick@parcs.ath.cx> <1434466413-28892-1-git-send-email-patrick@parcs.ath.cx> <87mvym67i5.fsf_-_@redhat.com> From: Patrick Palka Date: Thu, 23 Jul 2015 19:33:00 -0000 Message-ID: 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) To: Sergio Durigan Junior Cc: "gdb-patches@sourceware.org" Content-Type: text/plain; charset=UTF-8 X-SW-Source: 2015-07/txt/msg00662.txt.bz2 On Thu, Jul 23, 2015 at 2:42 PM, Sergio Durigan Junior 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. Thanks for the heads up. When doing gdb_exit followed by gdb_start, in the output log sometimes we have (this is printed shortly before the first FAIL) (gdb) ... Remote debugging from host 127.0.0.1 monitor exit spawn ... GNU gdb (GDB) 7.10.50.20150723-cvs ... Other times we have (this is printed shortly before the second FAIL) (gdb) ... Remote debugging from host 127.0.0.1 monitor exit (gdb) spawn ... GNU gdb (GDB) 7.10.50.20150723-cvs ... The literal difference being the "(gdb) " prompt printed before the "spawn" message. In the first case (where the "(gdb) " prefix is not there) the history file does not seem to be written/appended to. In the second case (when the "(gdb) " prefix is there) the history file is properly written/appended to (but it still FAILs because we're missing the command history from before the first case). So the race, if there is one, may have something to do with whether or not the "(gdb) " prompt gets printed after doing "monitor exit". Or maybe not. I'll do more analysis later.