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

[Sergio Durigan Junior]

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.

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/