From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 77960 invoked by alias); 17 Aug 2015 23:29:36 -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 77951 invoked by uid 89); 17 Aug 2015 23:29:35 -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-f42.google.com Received: from mail-oi0-f42.google.com (HELO mail-oi0-f42.google.com) (209.85.218.42) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Mon, 17 Aug 2015 23:29:34 +0000 Received: by oio137 with SMTP id 137so90834983oio.0 for ; Mon, 17 Aug 2015 16:29:32 -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=Vx/B6lEtqrQgTHyy+Kv61ayBkcJFoMlGAMBIchDebc8=; b=dsLpJopnTHyUUlIrjOlOo5SwQdcLgBbdWwBVWZUnBbKidODcdkTvNmHJDiGSSqpNOX e/mKqCodkKNxcHe8L3qQ91NesFgrTffhviPrvUOqiBppEbYTgKLLPEK7eRE8/Fd/8Xgb Ql4a3YTlq/jps6fdLL0PcY2N9RZ3WGjcO0JXJUzeNjvLJ8TFdG7FiBUypLJSxTgoCeDJ Lt++VwKih79mrSEXi0uYh7bKFdIG65hsCMHwFVREsh/vdSbVz3C6XSnG51Z5v1t769jo Sz41H1VUiRI4b7EjDagVZMGk5GiveSDzmSO7Q7y+OXTmIDlJsGHl7CoG5Avynvq2AwW7 OX+g== X-Gm-Message-State: ALoCoQlIPHA33Czg7YkTv84dbKWuFxOgJ8AjbIGbLi1LcI1g8/Ltz3bN7OSq1n0NdNQC94SzO1BO X-Received: by 10.202.73.21 with SMTP id w21mr3154628oia.23.1439854172364; Mon, 17 Aug 2015 16:29:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.56.202 with HTTP; Mon, 17 Aug 2015 16:29:12 -0700 (PDT) In-Reply-To: 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 23:29: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/msg00449.txt.bz2 On Mon, Aug 17, 2015 at 4:10 PM, Patrick Palka wrote: > 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. 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.