From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 66466 invoked by alias); 17 Aug 2015 20:10:26 -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 66451 invoked by uid 89); 17 Aug 2015 20:10:25 -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-f46.google.com Received: from mail-oi0-f46.google.com (HELO mail-oi0-f46.google.com) (209.85.218.46) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Mon, 17 Aug 2015 20:10:24 +0000 Received: by oiev193 with SMTP id v193so86952579oie.3 for ; Mon, 17 Aug 2015 13:10:22 -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=ULSe7kP/WEi1M6a3vYUexHOv5dGEQKe2EW1HNsjCWK8=; b=DRQc/OmQKRpEAra+94KbyWQkZaeZ3IYW3hzNipd1FB01Hd4TkdxDO8yAY5zvxQPlRi 4vMki02Wlq7i7OL9SjJ1zwiSMi7LEDdQVc/y7rNb/Xn+tbG5rccSq2yiF/J9WgOwl2v/ vWJq11+aVzL2wW11DOnI37riF+s8d+uYMIg4JDCFStrGPsDvRU+qYkIamKWo5Xg/WCN/ 7aMr7S56IxYg1a/SDhPrgM8vH3kN748jxkPnnD+APJ2YcjcXzyvh/5ZS8PwHUeivocji IoLfrKX+XQaJSUwML+54g2oabFBf4rLwNNbwUVMONIGeiwVk7XS08Sc+XJTWAdNavIfH hLLw== X-Gm-Message-State: ALoCoQkymHwjY7AexEJdbA6hz+k41dYVAsLsvE1e+DEvFa8T5wBF1GPo0uAqmPjbz62zLCvfa+TO X-Received: by 10.202.196.82 with SMTP id u79mr2595421oif.78.1439842222581; Mon, 17 Aug 2015 13:10:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.56.202 with HTTP; Mon, 17 Aug 2015 13:10:03 -0700 (PDT) In-Reply-To: <55D1E991.9080504@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> <87zj1un7ro.fsf@redhat.com> <55CD27AE.2090002@redhat.com> <55D1E991.9080504@redhat.com> From: Patrick Palka Date: Mon, 17 Aug 2015 20:10:00 -0000 Message-ID: Subject: Re: Racy failures on gdb.base/gdbinit-history.exp (native-extended-gdbserver/-m64) To: Pedro Alves Cc: Sergio Durigan Junior , "gdb-patches@sourceware.org" Content-Type: text/plain; charset=UTF-8 X-SW-Source: 2015-08/txt/msg00443.txt.bz2 On Mon, Aug 17, 2015 at 10:02 AM, Pedro Alves 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.