rr assertion due to GDB bug

[Keno]

This is with GDB version

GNU gdb (Ubuntu 9.0.50.20191119-0ubuntu1) 9.0.50.20191119-git
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

The sequence of commands I enter is:

handle SIGSEGV pass nostop noprint
handle SIGTRAP pass nostop noprint
hbreak *0xf7f736db

The full rr log is available here: https://gist.githubusercontent.com/Keno/6b100e21e505f5d98a2593695717405e/raw/e3b8dee2bf2804969be16930ef6cb799cef2d735/rrlog
The rr assertion failure is:

[FATAL /home/keno/rr-clean/src/ReplayTimeline.cc:684:remove_watchpoint()]
 (task 109051 (rec:108827) at time 9275)
 -> Assertion `has_watchpoint_at_address(t, addr, num_bytes, type)' failed to hold.

The relevant gdb packages causing the failure are:

[GdbConnection] raw request Z1,f7f736db,1
[GdbConnection] gdb requests setbreakpoint (addr=0xf7f736db, len=1)
[...]
[GdbConnection] raw request z1,f7f736db,1
[GdbConnection] gdb requests removebreakpoint (addr=0xf7f736db, len=1)
[...]
Breakpoint 1, 0xf7f736db in ?? ()
(rr) c
Continuing.
[...]
[GdbConnection] raw request Z0,f7f736db,1
[GdbConnection] gdb requests setbreakpoint (addr=0xf7f736db, len=1)
[...]
[GdbConnection] raw request z1,f7f736db,1
[GdbConnection] gdb requests removebreakpoint (addr=0xf7f736db, len=1)

Notice that gdb requested a software breakpoint the second time around, but still tried to remove it as a hardware breakpoint, triggering the rr assertion.

[Keno]

It's probably getting confused by my trying to block SIGTRAP. Maybe we should add an rr command line flag that renames recorded SIGTRAPs to some other signal to help gdb out.

[rocallahan]

does that SIGTRAP handler work with gdb without rr?

[Keno]

I don't know. GDB's signal handing code is extremely brittle. I've never gotten it to do what I actually want. It does usually work fairly well with rr though.

[rocallahan]

Maybe we should add an rr command line flag that renames recorded SIGTRAPs to some other signal to help gdb out.

That seems a bit ad-hoc.

I think the most important thing to do is file an upstream gdb bug and maybe fix it.

If fixing it is impractical or you need a solution fast then we could add a workaround for the gdb bug I guess.

[Keno]

I've managed to debug gdb, and filed an upstream issue with a proposed patch that fixes this issue for me: https://sourceware.org/bugzilla/show_bug.cgi?id=25741

[rocallahan]

Thank you very very much!

[Keno]

Fixed in https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=7f32a4d5aef1891813d5e4a4bd97151797edc82d