SIGSEGV when debugging large binary with DWARF data

[mcd1992]

SIGSEGV when debugging large binary with DWARF data

[trufae]

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 :)

[mcd1992]

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 oob will then trigger it.

DEBUG: empty symbol name
DEBUG: Symbol name outside the strtab section
DEBUG: Truncated corrupted section name: conditional<false, const Eigen::CwiseUnaryOp<Eigen::internal::scalar_conjugate_op<double>, const Eigen::CwiseBinaryOp<Eigen::internal::scalar_sum_op<double, double>, const Eigen::CwiseBinaryOp<Eigen::internal::scalar_sum_op<double, double>, const Eigen::CwiseBinaryOp<Eigen::internal::scalar_product_op<double, double>, const Eigen::CwiseNullaryOp<Eigen::internal::scalar_constant_op<double>, const Eigen::Matrix<double, -1, 1, 0, -1, 1> >, const Eigen::Map<const Eigen::Matrix
DEBUG: Truncated corrupted section name: conditional<false, const Eigen::CwiseUnaryOp<Eigen::internal::scalar_real_op<double>, const Eigen::CwiseBinaryOp<Eigen::internal::scalar_sum_op<double, double>, const Eigen::CwiseBinaryOp<Eigen::internal::scalar_sum_op<double, double>, const Eigen::CwiseBinaryOp<Eigen::internal::scalar_product_op<double, double>, const Eigen::CwiseNullaryOp<Eigen::internal::scalar_constant_op<double>, const Eigen::Matrix<double, -1, 1, 0, -1, 1> >, const Eigen::Map<const Eigen::Matrix<doub
DEBUG: Truncated corrupted section name: conditional<false, Eigen::CwiseUnaryView<Eigen::internal::scalar_real_ref_op<double>, Eigen::CwiseBinaryOp<Eigen::internal::scalar_sum_op<double, double>, const Eigen::CwiseBinaryOp<Eigen::internal::scalar_sum_op<double, double>, const Eigen::CwiseBinaryOp<Eigen::internal::scalar_product_op<double, double>, const Eigen::CwiseNullaryOp<Eigen::internal::scalar_constant_op<double>, const Eigen::Matrix<double, -1, 1, 0, -1, 1> >, const Eigen::Map<const Eigen::Matrix<double, -1
DEBUG: Truncated corrupted section name: conditional<false, Eigen::CwiseUnaryOp<Eigen::internal::scalar_conjugate_op<double>, const Eigen::Transpose<const Eigen::CwiseBinaryOp<Eigen::internal::scalar_sum_op<double, double>, const Eigen::CwiseBinaryOp<Eigen::internal::scalar_sum_op<double, double>, const Eigen::CwiseBinaryOp<Eigen::internal::scalar_product_op<double, double>, const Eigen::CwiseNullaryOp<Eigen::internal::scalar_constant_op<double>, const Eigen::Matrix<double, -1, 1, 0, -1, 1> >, const Eigen::Map<co

[trufae]

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.

• dont load the dwarf info -e bin.dbginfo=false
• implement parsing this info everytime is needed instead of mapping it all in a hashtable in memory
• use a better data storage instead of a hashtable

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?

[mcd1992]

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 6.6.10-arch1-1. The whole reason I'm wanting to open this though is for the DWARF data so I can generate zignatures / FLIRT for the debug-less versions. I could probably just dump the symbols+address and manually af name them before making zigs.

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.

[trufae]

I can't reproduce. on ubuntu i get the process killed because the kernel is picky and just kills the process when eats a lot of memory. but i can open this file without issues in macOS after consuming 50GB of ram. so this is not a sigsegv for me. Btw , after loading all the dwarf info, r2 eats about 16-20GB of ram.

[mcd1992]

Ah I haven't tested with a system above 32G. Using ulimit -Sv 8000000 or any value smaller than radare needs to build the full hashtables should trigger it.

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.

[trufae]

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.