Closed Fedr closed 1 month ago
Recreated.
I happen to contribute the <stacktrace>
feature, and I have no clear idea what is going on and how to fix it.
Generally, arbitrary API's are not supported in DllMain
because of the loader lock problem.
See Dynamic-Link Library Best Practices.
However, I don't see this hang as an occurrence of the loader lock problem, it looks like something else.
Also, I don't see a documented way how to detect the problematic situation. A call from DllMain
can be detected by querying loader lock state. But there's no documented way to query the loader lock state. Also, it is not clear ow strictly this problem is connected with DllMain
.
It is possible that switching the implementation from DbgEng.dll
to DbgHelp.dll
can fix the problem, because on <stacktrace>
implementation side it hangs in this place, which would not be needed in case of DbgHelp.dll
usage:
Maybe it can be seen better from maintainers' side with Windows source available.
This looks by design to me - even if the loader lock specifically isn't the cause, calling STL functions during DLL attach is fraught with peril because of the loader lock, so I don't think we can support it in general. I'm not a DLL expert though, so I'll leave this issue open for now.
We talked about this at the weekly maintainer meeting and concluded that this is by design - we can't support stringizing stacktraces during DLL attach.
I've reported this as one of DevCom-10692305 issues.
I think we should attempt to support this scenario if underlying API can allow it.
Describe the bug
If
to_string( std::stacktrace::current() )
first called during DLL loading, then the application can hang forever.Test case
Put a global variable in your DLL calling
to_string( std::stacktrace::current() )
in its constructor:then during loading of this DLL by means of
LoadLibraryW
, for example, on Windows 11 the program hangs with the stack as follows:Expected behavior
I would expect that
to_string( stacktrace )
will return an empty string or an error, but does not get stuck.STL version
Visual Studio 2022 version 17.9.2
Additional context
The problem is that I try logging stacktraces in my exception handler, which can be invoked during DLL loading as well (and global object is just to simplify demonstration). It is extremely inconvenient that I must track by myself the moments when stacktrace can be used and when it is not because of possible hangs.