[Bug] Launching Chrome with GEF is 50x (or more) slower than normal GDB

[seanptmaher]

GEF+GDB version

GEF: (Standalone)
Blob Hash([redacted].gdbinit-gef.py): 1a409c397646df9c0b8549d576cd7c7f8ec1ef47
SHA256([redacted].gdbinit-gef.py): f096ff3bf50df08dbbc698a919360014f86f1eea315011cdabebd72a30a5bce8
GDB: 13.2
GDB-Python: 3.11

Operating System

Distributor ID: Debian Description: Debian GNU/Linux rodete

Describe the issue you encountered

When ring a freshly built debug copy of chromium, I'm dealing with very very slow launch times. On a normal GDB, it launches within 5 seconds, but with GEF, it takes near 5 minutes to load what I'm assuming is the symbol files into memory. Worth noting that this occurs every run of the program, including relaunches in the same GDB session, meaning that GEF is unusable for my use case.

It also consumes about twice the memory, from 10G to 17G.

I have a feeling GEF just isn't built for this and this isn't fixable, but a confirmation on that would be nice.

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.

Compile chromium, then run it.

The instructions to do this are in detail here:
https://chromium.googlesource.com/chromium/src/+/main/docs/linux/build_instructions.md
https://chromium.googlesource.com/chromium/src/+/0e94f26e8/docs/linux_debugging.md

However, if you wish to reproduce this, it will take many hours of your day - cloning the repo takes a half hour on a gigabit connection last I checked, and consumes 100G of hard drive space, and building the repo without a distributed compiler might take a few hours depending on your setup.

Minimalist test case

N/A

Additional context?

No response

[hugsy]

Hi @seanptmaher,

Your case seems extreme, I've never heard of GEF penalizing a process (even browsers) by 50x. However I do know that GEF is used even to this day in web browser exploitation trainings which makes your situation even weirder, as if it was common, I believe I would've heard something about this already. It makes sense for it to slow down execution and increase memory use, but not by the extreme factors you indicated.

I don't really have time to go further into this personally but I'll leave this issue as-is if another dev has time to investigate deeper. If you want to improve the situation, you could provide some profiling information to help focus our attention on the component(s) taking the longest. If you know more people having the same issue, ask them to drop us a comment here. It might boost the priority for this.

Nonetheless, thanks for letting us know.

[seanptmaher]

Hey,

In those workshops, are they looking at an optimized build? Or is it a component build? If it's an optimized one it might make sense that it was faster due to there only being one object file rather than hundreds of smaller ones. I'll see if I can gather profiling data, I'm not familiar with how I would go about profiling python - I could run a perf one but I don't know if that would be useful for you.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. You can reopen it by adding a comment to this issue.

[stale]

This issue has been automatically closed because it has not had recent activity. If you are the owner of this issue, you can either re-open it and provide a more complete description; or create a new issue. Thank you for your contributions.