X64dbg: SymFromAddr performance (symbol cache)

[mrexodia]

The performance of this function is horrible when symbols are loaded. Solution: properly cache symbols in a fast data structure and make sure dbghelp is not used whenever possible.

[mrexodia]

Here is another instance of this happening (it causes really awful lag too):

[mrfearless]

Wonder if its possible to use minhook or something similar to redirect that SymGetLineFromAddrW64 to a better version that doesnt lag - could be worth looking at how wine or reactos or something else implements it: https://www.winehq.org/pipermail/wine-patches/2006-May/026451.html

[mrexodia]

I have full control over all the calls to SymGetLineFromAddrW64 so no hooks are needed. But this is indeed the idea. I have started implementing fast alternatives in symcache.cpp but I'm still thinking of a good way to populate that cache without completely lagging x64dbg on module load.

The issue lies in:

All DbgHelp functions, such as this one, are single threaded. Therefore, calls from more than one thread to this function will likely result in unexpected behavior or memory corruption. To avoid this, you must synchronize all concurrent calls from more than one thread to this function.

My current idea is to have a dedicated thread for dbghelp calls. Then on module load it calls DbgHelpThreadLoadModule which will immediately return and then populate the symbols in the background, putting them all in the cache at once to avoid any performance problems. I'm still thinking of downsides, but the only one I currently see is the additional complexity of managing an extra thread.

[mrfearless]

Off the top of my head only thing i can think off is if someone clicked on symbols tab and clicked a module and started searching for symbol names whilst a background thread was still processing and caching and the background thread was delayed for some reason (bug/searching etc?)

[mrexodia]

Ah that's a good one! In that case it'll signal the dbghelp thread that a
symbol enumeration was requested and if those symbols are still in progress
it will refresh the symbol list as soon as it can. In practice this will be
just a minor timing issue since the user is unlikely to immediately click
the symbol tab just after the module is loaded.
On Sun, 9 Apr 2017 at 03:11, fearless [e-mail] wrote:

Off the top of my head only thing i can think off is if someone clicked on
symbols tab and clicked a module and started searching for symbol names
whilst a background thread was still processing and caching and the
background thread was delayed for some reason (bug/searching etc?)

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/x64dbg/x64dbg/issues/747#issuecomment-292756599, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ACWCmaICQt-fvA8aBHeMlCakSn7wn1oFks5ruDBXgaJpZM4I0uLY
.