From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27095 invoked by alias); 17 Aug 2015 14:03:08 -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 27083 invoked by uid 89); 17 Aug 2015 14:03:08 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=no version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Mon, 17 Aug 2015 14:03:01 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (Postfix) with ESMTPS id 1966283F9E; Mon, 17 Aug 2015 14:03:00 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t7HE2wxi002253; Mon, 17 Aug 2015 10:02:58 -0400 Message-ID: <55D1E991.9080504@redhat.com> Date: Mon, 17 Aug 2015 14:03:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Patrick Palka CC: Sergio Durigan Junior , "gdb-patches@sourceware.org" Subject: Re: Racy failures on gdb.base/gdbinit-history.exp (native-extended-gdbserver/-m64) 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> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2015-08/txt/msg00423.txt.bz2 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? 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. Also, I think it's time to try to get all the buildslaves to use dejagnu master, to pick up http://lists.gnu.org/archive/html/dejagnu/2015-07/msg00005.html. Who knows, maybe that race/rogue kill could also explain this problem. The x86_64 Fedora slaves have been running with that for a while, and we no longer see attach-many-short-lived-threads.exp failures there, and we keep seeing them on the other slaves (which don't have that fix). Thanks, Pedro Alves