Re: [PATCH] New testcase for PR tui/25126 (staled source cache)

Luis Machado
2020-02-07T20:18:46Z

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