Re: [RFA] When getting the locno of a bpstat, handle the case of bp with null locations.

[Simon Marchi <simark@simark.ca>]

On 11/20/22 12:30, Philippe Waroquiers via Gdb-patches wrote:
> The test py-objfile.exp unloads the current file while debugging the process.
> This results in bpstat bs->b->loc to become nullptr.
> Handle this case in breakpoint.c:bpstat_locno.
> 
> Note: GDB crashes on this problem with an internal error,
> but the end of gdb summary shows:
>   ...
>                   === gdb Summary ===
> 
>   # of expected passes		36
> 
> The output also does not contain a 'FAIL:'.
> After the dix, the nr of expeted passes increased.
> 
> In the gdb.log output, one can see:
>   ...
>   Fatal signal: Segmentation fault
>   ----- Backtrace -----
>   0x55698905c5b9 gdb_internal_backtrace_1
>           ../../binutils-gdb/gdb/bt-utils.c:122
>   0x55698905c5b9 _Z22gdb_internal_backtracev
>   ...
> 
>   ERROR: Couldn't send python print(objfile.filename) to GDB.
>   ERROR: : spawn id exp9 not open
>       while executing
>   "expect {
>   -i exp9 -timeout 10
>           -re ".*A problem internal to GDB has been detected" {
>               fail "$message (GDB internal error)"
>               gdb_internal_error..."
>       ("uplevel" body line 1)
>       invoked from within
>   ....
> 
> Wondering if it might be possible to improve gdb_test to have
>   gdb_test "python print(objfile.filename)" "None" \
>       "objfile.filename after objfile is unloaded"
> reporting a failed result instead of just producing the internal error.

I ran the testsuite with the patch applied, I saw these unexpected
failures when running with native-gdbserver or
native-extended-gdbserver:

FAIL: gdb.base/step-over-syscall.exp: detach-on-fork=off: follow-fork=parent: break cond on target : fork: continue to marker
FAIL: gdb.base/step-over-syscall.exp: detach-on-fork=off: follow-fork=child: break cond on target : fork: continue to marker

I bisected, and it pointed to the locno patch again.  Probably the
expected patterns that need to be updated?

    continue^M
    Continuing.^M
    [New inferior 2 (process 1262224)]^M
    ^M
    Thread 1.1 "step-over-fork" hit Breakpoint 4.1, marker () at /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/step-over-fork.c:22^M
    22      marker () {}^M
    (gdb) FAIL: gdb.base/step-over-syscall.exp: detach-on-fork=off: follow-fork=parent: break cond on target : fork: continue to marker

However, I confirm it gets rid of the UNRESOLVEDs due to the ASan
complaints.  But I don't have time to look at the code right now, sorry.

Simon