From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 119029 invoked by alias); 8 Feb 2020 00:27:21 -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 119018 invoked by uid 89); 8 Feb 2020 00:27:21 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-10.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy= X-HELO: mail-wr1-f66.google.com Received: from mail-wr1-f66.google.com (HELO mail-wr1-f66.google.com) (209.85.221.66) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 08 Feb 2020 00:27:19 +0000 Received: by mail-wr1-f66.google.com with SMTP id c9so893044wrw.8 for ; Fri, 07 Feb 2020 16:27:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=embecosm.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=k9tlHvd04YG+ysyVwF7iph3prz/DfJ37anTSOkbMYNI=; b=RwiNcKqtw8MVgflIBc2lvFm6qpEz6yhPAe4OO8WjsW3SluubOK134kE5/6WDhJsTku wWm4o9AbuJTiRVBziXxPtfLY6UhibSlKnPSoNzWyFiXj+kMeR8JYbB+ZAjuqJQ08izPO yzokmi4NrtDOzp3cofaXY3/TRuFggdyu00cvB/G0hxLRLtn0ROERjHEYoOQcfH2xU7hH VcMh2G4xSjGJDD9HStNd/qU9XkVeHT2vybr7gNE0E9hGMqxSmqY3C1TwyZ2fVcJyhCOx jUGu3IrPX0HmF4C0hTC77hzHFTeGKgkkZ6hSRR0LTP1TyU7N+jXkdgwtPjIIZF8waHBy /tpg== Return-Path: Received: from localhost (host86-191-239-73.range86-191.btcentralplus.com. [86.191.239.73]) by smtp.gmail.com with ESMTPSA id p15sm5142801wma.40.2020.02.07.16.27.16 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 07 Feb 2020 16:27:16 -0800 (PST) Date: Sat, 08 Feb 2020 00:27:00 -0000 From: Andrew Burgess To: Sergio Durigan Junior Cc: Luis Machado , GDB Patches Subject: Re: [PATCH] New testcase for PR tui/25126 (staled source cache) Message-ID: <20200208002715.GL4020@embecosm.com> References: <20200206225943.26709-1-sergiodj@redhat.com> <4a3db909-8677-fb84-39cf-84495266fdd8@linaro.org> <20200207114712.GI4020@embecosm.com> <87sgjm9vf7.fsf@redhat.com> <87sgjm6un4.fsf@redhat.com> <87o8ua6ttp.fsf@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87o8ua6ttp.fsf@redhat.com> X-Fortune: Some Windows were made to be broken. X-Editor: GNU Emacs [ http://www.gnu.org/software/emacs ] User-Agent: Mutt/1.9.2 (2017-12-15) X-IsSubscribed: yes X-SW-Source: 2020-02/txt/msg00202.txt.bz2 * Sergio Durigan Junior [2020-02-07 15:11:46 -0500]: > On Friday, February 07 2020, I wrote: > > > 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. > > gdb.log gdb.sum > > (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. > > I think I found the issue. On symfile.c:reread_symbols, the check > performed to see whether the new objfile being loaded is different than > the previous one is based on calling 'stat' and checking 'st_mtime': > > ... > new_modtime = new_statbuf.st_mtime; > if (new_modtime != objfile->mtime) > { > printf_filtered (_("`%s' has changed; re-reading symbols.\n"), > objfile_name (objfile)); > ... > > According to stat(2), 'st_mtime' is actually 'st_mtim.tv_sec', which > means the precision of this field is given in seconds. Since Linux 2.6 > 'st_mtim's precision is given in nanoseconds, but we still use the > seconds field. > > Because the testing script runs so fast, it's really likely that the old > and the new files will have the same 'st_mtime'. Here's the output of > an 'fprintf' I put in the code: > > new_modtime = 1581105949, old_modtime = 1581105949 > > So yeah, we have a few options here: > > 1) For now, I think it's justifiable to use "sleep 1" in the code, to > force 'st_mtime' to be different between the two files. I think using sleep 1 is fine in this case, as the comment will now make it clear that it's not an arbitrary delay, but a specific _minimum_ delay to ensure the timestamp ticks over. > > 2) The GDB code could be modernized to use nanosecond precision, which > should solve this problem. Only if you want extra credit :) Thanks for taking the time (there must be a pun here somewhere) to investigate this. Thanks, Andrew > > Thanks, > > -- > Sergio > GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 > Please send encrypted e-mail if possible > http://sergiodj.net/ >