-
-
Notifications
You must be signed in to change notification settings - Fork 2.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SIGSEGV when debugging large binary with DWARF data #22569
Comments
Note it doesn't happen immediately and there is some debug notes a few minutes prior to it segfaulting. Might add some extra R_LOG_DEBUGs to the libr/bin/dwarf.c or shlr/sdb/src/ht.inc.c and see where its happening. If I open with -nn it doesn't happen but doing a
|
Well this is an out of memory problem caused by your kernel (debian / ubuntu?) despite we can optimize the memory usage in dwarf importing i think it could be better to find alternative solutions.
The assembly you pasted here shows a nullptr + 0x28 delta, so it seems there's an allocation that fails, but will be good to know which one it is. and as long as this depends on the system i will probably not be able to reproduce in here. Can you upload that binary somewhere? |
It looks like just the split debug file triggers it as well, no need to eu-unstrip. https://gofile.io/d/DNUA0G This is on arch's kernel The same thing happens with a stock Unreal Engine 5 game, the .debug/DWARF file is 2G+ and will cause radare to OOM even on a system with 32G RAM. |
Ah I haven't tested with a system above 32G. Using I guess if it's just a side-effect of how radare does DWARF parsing the issue is more about your last 2 bullet points on re-writing the parser/hashtable implementation. |
Agree, the current storage method for dwarf info does not perform well for large files like this, but afaik the crash is not caused by a bug in r2 code. So it will be better to redesign the way this information is stored in r2 instead of depending on a hashtable. FIxing things by throwing more metal is not the way to go. |
i've introduced a void* to hold a private data storage to replace the current hashtable approach without breaking the ABI promise, this way i can fix that without holding the release for more time. so moving this ticket for 5.9.2 or so :) |
Environment
Description
When opening a large (2.3G) ELF bin with DWARF symbols radare will consume over 8G of RAM and get oom-killed. If I set a soft ulimit and let it run again it will SIGSEGV in a memcpy call. See bottom gdb notes. I'm not sure why the debug symbols for libr_util.so aren't showing up; I'm guessing something weird with the macros in the hashtable source C? Let me know if there's any extra info I can get from GDB.
Test
The binary is large so I can't easily distribute it but it can be downloaded/made.
/palworld/Pal/Binaries/Linux/merged: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.10.93, BuildID[xxHash]=a37ec78630b980cc, with debug_info, not stripped
You'll need to get the old bins for the game dedicated server Palworld with something like https://github.com/SteamRE/DepotDownloader and get the old manifest files https://steamdb.info/depot/2394012/history/?changeid=M:4603741190199642564
Then eu-unstrip the executable and the .debug ELF together and just
r2 merged.bin
GDB output
The text was updated successfully, but these errors were encountered: