[Bug] Weird memory mapping with rr replay

[Manouchehri]

GEF+GDB version

gef➤  version
GEF: (Standalone)
Blob Hash(/root/gef.py): 3300b1c858cbd6765e9877e18f98fa30c03c4fdf
SHA256(/root/gef.py): acb7142bb4ecab5f5a867fcb583fc58e12d7f24829b8a9fdcf596f8e6eb3c18a
GDB: 12.1
GDB-Python: 3.10

Operating System

Distributor ID: Ubuntu Description: Ubuntu 22.04.3 LTS

Describe the issue you encountered

vmmap results really weird results, and xinfo doesn't work.

gef➤  vmmap
[ Legend:  Code | Heap | Stack ]
Start              End                Offset             Perm Path
0x0000558aefc81318 0x0000558aefc81334 0x0000000000000318 rw- .interp
0x0000558aefc81338 0x0000558aefc81368 0x0000000000000338 rw- .note.gnu.property
0x0000558aefc81368 0x0000558aefc8138c 0x0000000000000368 rw- .note.gnu.build-id
0x0000558aefc8138c 0x0000558aefc813ac 0x000000000000038c rw- .note.ABI-tag
0x0000558aefc813b0 0x0000558aefc813d4 0x00000000000003b0 rw- .gnu.hash
0x0000558aefc813d8 0x0000558aefc81bb8 0x00000000000003d8 rw- .dynsym
0x0000558aefc81bb8 0x0000558aefc81f85 0x0000000000000bb8 rw- .dynstr
0x0000558aefc81f86 0x0000558aefc8202e 0x0000000000000f86 rw- .gnu.version
0x0000558aefc82030 0x0000558aefc820c0 0x0000000000001030 rw- .gnu.version_r
0x0000558aefc820c0 0x0000558aefc83080 0x00000000000010c0 rw- .rela.dyn
0x0000558aefc83080 0x0000558aefc836f8 0x0000000000002080 rw- .rela.plt
0x0000558aefc84000 0x0000558aefc84025 0x0000000000003000 r-x .init
0x0000558aefc84030 0x0000558aefc84490 0x0000000000003030 r-x .plt
0x0000558aefc84490 0x0000558aefc844a0 0x0000000000003490 r-x .plt.got
0x0000558aefc844a0 0x0000558aefc848f0 0x00000000000034a0 r-x .plt.sec
0x0000558aefc848f0 0x0000558aefc93761 0x00000000000038f0 r-x .text
0x0000558aefc93764 0x0000558aefc93776 0x0000000000012764 r-x .fini
0x0000558aefc94000 0x0000558aefc97eb4 0x0000000000013000 rw- .rodata
0x0000558aefc97eb4 0x0000558aefc98030 0x0000000000016eb4 rw- .eh_frame_hdr
0x0000558aefc98030 0x0000558aefc98b70 0x0000000000017030 rw- .eh_frame
0x0000558aefc9a060 0x0000558aefc9a070 0x0000000000018060 -w- .ctors
0x0000558aefc9a070 0x0000558aefc9a080 0x0000000000018070 -w- .dtors
0x0000558aefc9a080 0x0000558aefc9abb0 0x0000000000018080 -w- .data.rel.ro
0x0000558aefc9abb0 0x0000558aefc9ad60 0x0000000000018bb0 -w- .dynamic
0x0000558aefc9ad60 0x0000558aefc9b000 0x0000000000018d60 -w- .got
0x0000558aefc9b000 0x0000558aefc9b098 0x0000000000019000 -w- .data
0x0000558aefc9b0a0 0x0000558aefc9b1d0 0x0000000000019098 --- .bss
0x0000000000000000 0x0000000000000049 0x0000000000019098 r-- .gnu_debugaltlink
0x0000000000000000 0x0000000000000034 0x00000000000190e4 r-- .gnu_debuglink

Do you read the docs and look at previously closed issues/PRs for similar cases?

Yes

Architecture impacted

• X86
• X64
• ARM
• ARM64
• MIPS
• MIPS64
• PPC
• PPC64
• RISCV

Describe your issue. Without a proper reproduction step-by-step, your issue will be ignored.

Prior to running rr (https://github.com/rr-debugger/rr/wiki/Building-And-Installing), I set the config with:

gef config gef.disable_target_remote_overwrite True
gef save

rr record date
rr replay

Minimalist test case

No response

Additional context?

https://discord.com/channels/705160148813086841/705160148813086843/1195422070385934376

[Manouchehri]

To confirm, this did used to work fine with the gef.py file I have from early 2020.

[Manouchehri]

546f4b1 is the breaking commit.

343cd23 is the last working commit.

[ValekoZ]

I could repro this.
It looks like the issue is that GEF tries to sync /proc/<pid>/* with the PID of the recorded process, which does not exist anymore.

I think it would be nice to handle the cases where these files can't be synced differently (maybe the same way as it was before 343cd23 ?), even with a limited support (not all commands available) if some features can't work without these files.