From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15167 invoked by alias); 7 Feb 2020 19:54:19 -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 15159 invoked by uid 89); 7 Feb 2020 19:54:18 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-4.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy=intrigued X-HELO: us-smtp-1.mimecast.com Received: from us-smtp-delivery-1.mimecast.com (HELO us-smtp-1.mimecast.com) (207.211.31.120) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 07 Feb 2020 19:54:17 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1581105255; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=2g/u4wjHaYZQto8QvgmNxgmcUkahTosJtImGVsbuPEE=; b=UNM2JBg60o39D+nT9LOQg/EuJ/rm0PYCuTx+HRTgAT9nVXGIatWAv75X1qaxOdDe8b3XYP iXPs+81GpeGEhvslf95MJRFmGS2CtBhltd0GrO+lfqifnKCvOsf1lt3Xy8fTy+yycG/R/b 6Bb/tW0WOWPWcR+gmGwO6utWHw0nLJA= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-7-6EcwEBsqNxKDYqHEnj76lA-1; Fri, 07 Feb 2020 14:54:09 -0500 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id D6E8B10054E3; Fri, 7 Feb 2020 19:54:07 +0000 (UTC) Received: from localhost (unused-10-15-17-196.yyz.redhat.com [10.15.17.196]) by smtp.corp.redhat.com (Postfix) with ESMTP id AB3545DA7D; Fri, 7 Feb 2020 19:54:07 +0000 (UTC) From: Sergio Durigan Junior To: Andrew Burgess Cc: Luis Machado , GDB Patches Subject: Re: [PATCH] New testcase for PR tui/25126 (staled source cache) References: <20200206225943.26709-1-sergiodj@redhat.com> <4a3db909-8677-fb84-39cf-84495266fdd8@linaro.org> <20200207114712.GI4020@embecosm.com> <87sgjm9vf7.fsf@redhat.com> Date: Fri, 07 Feb 2020 19:54:00 -0000 In-Reply-To: <87sgjm9vf7.fsf@redhat.com> (Sergio Durigan Junior's message of "Fri, 07 Feb 2020 12:09:00 -0500") Message-ID: <87sgjm6un4.fsf@redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2020-02/txt/msg00181.txt.bz2 On Friday, February 07 2020, I wrote: > On Friday, February 07 2020, Andrew Burgess wrote: >> I'm not suggesting that you need to track down the cause of this >> issue, but I agree with Luis that we should avoid arbitrary short >> pauses. >> >> I think you could probably use gdb_get_line_number to solve this >> problem, something like this completely untested code: >> >> # In some cases it has been observed that the file-system doesn't >> # immediately reflect the rename. Here we wait for the file to >> # reflect the expected new contents. >> proc wait_for_rename {} { >> global srcfile >> for { set i 0 } { $i < 5 } { incr i } { >> if { ![catch { gdb_get_line_number \ >> "pattern only matching the new line" \ >> ${srcfile} }] } { >> return >> } >> sleep 1 >> } >> error "file failed to rename correctly" >> } > > Ah, cool. I'll adjust that to the code. Thank you. OK, after trying your code, I can say that the problem is not on TCL. wait_for_rename returns successfully, and I've checked that gdb_get_line_number returns the correct value for the line. So, for TCL, the rename succeeded. Here's an interesting thing: I put a gdb_interact after the second "run" command, and then did: (gdb) list 35 printf ("hello\n"); /* break-here */ (gdb) shell gdb.=20=20=20=20=20 gdb.log gdb.sum=20=20 (gdb) shell outputs/gdb.base/cached-source-file/cached-source-file foo hello See how, for GDB, the inferior doesn't have the 'printf ("foo\n");' line, but when I run it externally I can see "foo" being printed? This means that GCC compiled the correct file, but GDB did not load it again, somehow. I find it extremely interesting how putting a "sleep 1" after the rename magically solves this problem. I would be less intrigued if we had to put "sleep 1" after "gdb_compile", because then it would hint at some race condition happening with GCC and GDB (very unlikely, but easier to understand). I didn't want to, but I guess I'll have to keep investigating this. Unless you (or someone) have any other ideas. Thanks, --=20 Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible http://sergiodj.net/