[Bug] extremely slow when debugging the linux kernel

[Kyle-Kyle]

GEF+GDB version

gef: latest main branch: ed10244b0fe4665e8ee03fa326b1b1c711b39563
gdb: Ubuntu 15.0.50.20240403-0ubuntu1

Operating System

Ubuntu 24.04

Describe the issue you encountered

when attaching to a linux qemu, gef will get stuck within reset_all_caches for some time. And every hook_stop_handler invocation takes about 15s to finish.

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

No

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.

target remote :1234 to a qemu instance and it will get stuck. After a long time, gef will finish loading, but every single step takes more than 10 seconds.

Minimalist test case

Use this field for a minimal code to compile and spot the issue:

// compile with gcc -fPIE -pic -o my_issue.out my_issue.c
int main(){ return 0; }

You can also provide a Dockerfile if you prefer

Additional context?

• Screenshots
• Callstack
• Coredumps
• If possible and useful, please upload the binary

[Kyle-Kyle]

I modified gef for a bit to see how long it takes to execute a hook_stop_handler
And it is 44.645326137542725

[Kyle-Kyle]

turns out the gdb shipped with ubuntu 24.04 has a bug with the monitor info mem command, when communicating with QEMU, it may miss some packets and eventually takes 22s to finish.
During cache reset, gef will try to invoke monitor info mem every time to get the new memory mapping, which gets stuck at this command.

I guess this technically isn't gef's fault. But I'll still leave it here FYI.

[Grazfather]

Is it calling monitor info mem more than once per stop? If so, then it shouldn't, and that's a bug.

We have to update the maps, though, because they can change and if we don't clear them the data shown can be inaccurate.