Repository navigation
fix(windows): ensure null-terminated strings for SymLoadModule64 - #368
Conversation
In get_mod_info::operator(), ret.image_name and ret.module_name were previously copied into std::vector<char> via range [begin(), end()). This omitted the terminating '\0', resulting in out-of-bounds reads when SymLoadModule64 traversed past the buffer. Furthermore, if either string was empty, accessing element 0 (&img[0] / &mod[0]) caused undefined behavior / crashes. Pass null-terminated strings using ret.image_name.c_str() / ret.module_name.c_str() (or nullptr when empty) instead. Fixes bombela#360.
|
Confirming this fix with a real-world case. On Windows x64 (MSVC 2022; dbghelp 10.0.26100, also 6.11) this crashed our unit tests about once in 100 runs. Every TraceResolver construction calls SymLoadModule64 once per loaded module. dbghelp converts both names with MultiByteToWideChar(..., -1, ...), so without the terminating NUL it reads past the end of the vector until it finds a zero byte. It faults when the heap block ends at an unmapped page:
The debug heap hides it: no crashes in 200 runs under a debugger. With the normal heap (cdb -hd) it crashed in 10 of 300 runs, and in none of 300 once the names kept their terminating NUL, which is what this PR does. The diff looks right to me. The description seems to come from another PR (FreeBSD signal headers), fixing it would make review easier. Fixes #360. |
Summary
On FreeBSD, including <sys/signal.h> directly without prior POSIX system definitions can cause symbol conflicts with standard signal structures.
Changes
Testing
Fixes #360