Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Luis Machado <luis.machado@linaro.org>
To: Sergio Durigan Junior <sergiodj@redhat.com>
Cc: Andrew Burgess <andrew.burgess@embecosm.com>,
	GDB Patches <gdb-patches@sourceware.org>
Subject: Re: [PATCH] New testcase for PR tui/25126 (staled source cache)
Date: Fri, 07 Feb 2020 20:18:00 -0000	[thread overview]
Message-ID: <CAD2_up84vkM=OSTj1VK93LofEvNSJWX+3basekEGtrEb=LksAg@mail.gmail.com> (raw)
In-Reply-To: <87sgjm6un4.fsf@redhat.com>

On Fri, Feb 7, 2020, 20:54 Sergio Durigan Junior <sergiodj@redhat.com>
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.
>

Wild guess... Is the operation of renaming and reloading back in gdb
executing quickly enough that the bfd cache doesn't notice a change (lack
of timestamp precision in the filesystem)? This is assuming the object file
is the same between loads.


> 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/
>
>


  parent reply	other threads:[~2020-02-07 20:18 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-06 23:00 Sergio Durigan Junior
2020-02-07  9:41 ` Luis Machado
2020-02-07 11:47   ` Andrew Burgess
2020-02-07 17:09     ` Sergio Durigan Junior
2020-02-07 19:54       ` Sergio Durigan Junior
2020-02-07 20:11         ` Sergio Durigan Junior
2020-02-08  0:27           ` Andrew Burgess
2020-02-07 20:18         ` Luis Machado [this message]
2020-02-08  9:42           ` Luis Machado
2020-02-07 17:07   ` Sergio Durigan Junior
2020-02-10 19:09 ` [PATCH v2] " Sergio Durigan Junior
2020-02-10 19:33   ` Luis Machado
2020-02-10 20:03     ` Sergio Durigan Junior
2020-02-10 20:02 ` Sergio Durigan Junior
2020-02-10 21:55   ` Luis Machado
2020-02-11 11:10   ` Andrew Burgess
2020-02-11 16:38     ` Sergio Durigan Junior

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAD2_up84vkM=OSTj1VK93LofEvNSJWX+3basekEGtrEb=LksAg@mail.gmail.com' \
    --to=luis.machado@linaro.org \
    --cc=andrew.burgess@embecosm.com \
    --cc=gdb-patches@sourceware.org \
    --cc=sergiodj@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox