multithreadingwinapidbghelpdia-sdkdbgeng

DbgHelp vs DbgEng vs DIA SDK in regards to thread safety


All these APIs (DbgHelp, DbgEng, DIA SDK) can be used to recover function name/source file location from function pointers, so are usable to decrypt stack traces.

However, every DbgHelp function has the following remark:

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.

As for DbgEng, there aren't such claims, however it seems that it is based on DbgHelp, so cannot be thread-safe: even if DbgEng guards every call to DbgHelp, there may be calls to DbgHelp not from DbgEng, but directly from the user's code.

I'm afraid if DIA SDK is also implemented using DbgHelp.

So is there any robust symbols API that can be used in a library designed for a multithreaded application?


Solution

  • DIA SDK is assumed to be a thread safe solution.

    There's an issue in Boost.Stacktrace repo that asks for switching to DIA SDK. Unsafety of DbgHelp and DbgEng is mentioned there.

    Also there's an option to roll own implementation; a possible starting point is here: https://github.com/microsoft/microsoft-pdb