[Bug] Missing update of local /proc/{pid}/maps in remote session when new shared library is loaded

[MrNbaYoh]

GEF+GDB version

GDB: 13.2
GDB-Python: 3.11

Operating System

Manjaro Linux

Describe the issue you encountered

When a program in a remote session loads additional shared library after it started, the remote_objfile_event_handler:

gef/gef.py

Lines 11246 to 11258 in 570cc03

	def remote_objfile_event_handler(self, evt: "gdb.events.NewObjFileEvent") -> None:
	dbg(f"[remote] in remote_objfile_handler({evt.new_objfile.filename if evt else 'None'}))")
	if not evt or not evt.new_objfile.filename:
	return
	if not evt.new_objfile.filename.startswith("target:") and not evt.new_objfile.filename.startswith("/"):
	warn(f"[remote] skipping '{evt.new_objfile.filename}'")
	return
	if evt.new_objfile.filename.startswith("target:"):
	src: str = evt.new_objfile.filename[len("target:"):]
	if not self.sync(src):
	raise FileNotFoundError(f"Failed to sync '{src}'")
	return

downloads the shared library from the remote and store it in the local folder.
However, it does not update the local /proc/{pid}/maps file, leading to wrong vmmap outputs (and maybe other erroneous results).

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.

1. Start a remote debugging session on a program that loads additional shared libraries with dlopen for example.
2. Run the program and tries vmmap, the additional shared library won't show in the output.

Minimalist test case

No response

Additional context?

No response

[hugsy]

Which gef version are you using?

I cannot reproduce: it works well with this

cat meh.c << EOF
#include <stdio.h>
#include <dlfcn.h>
int main()
{
        __asm__("int3");
        void** handle = dlopen("/usr/local/lib/libkeystone.so.0", RTLD_NOW);
        printf("handle = %p -> %p\n", handle, *handle);
        __asm__("int3");
        dlclose(handle);
        __asm__("int3");
        return 0;
}
EOF

and

make meh
gdbserver localhost:1234 ./meh

on start, no libkeystone

but on the 2nd int3 libkeystone shows

If you think there is a bug, provide a detail step-by-step.

[pnck]

@hugsy Hi, I might encounter a similar problem, but I'm not sure whether it is a bug. Have you tried printing the vmmap for a remote process attached by gdbserver? I'm wondering if gef updates the mapping when the remote target is loading new libs.

[hugsy]

@pnck See the comment above. It works well. Provide a step-by-step to reproduce reliably from the main version if you think there's a bug. Otherwise I'll close the issue.

[pnck]

@hugsy Sorry I didn't read carefully.

I tried a couple of versions and see it seems fixed on the main branch.

I can reproduce with docker on the 2024.01 tagged version, which is likely the version I downloaded. (I remember I manually downloaded it from somewhere, probably the release page.)

reproduce on the older version:

• docker run --rm -it --privileged -p1234:1234 --name tmp ubuntu:22.04
• (inside docker) apt update && apt install build-essential gdbserver
• build a minimal program: printf '#include<stdio.h>\nmain(){return 0;}' | gcc -xc -
• attach: gdbserver :1234 a.out
• connect the gdbserver from outside docker
• tb main; c
• vmmap doesn't show libc

[hugsy]

Thanks @pnck that's much more useful!
I can reproduce the bug now on 2024.01, and I'm fairly sure this bug was killed with many others in #1046 Since I can reproduce it, I'll be adding some non-regression tests so we're able to catch those in the future.

Since it's fixed in main and already many more bugs were fixed in there too, we will probably create another release very soon, including those changes. So for now please keep using main.

Cheers!