2016-12-18 17:03 GMT+03:00 Peter Dimov
Niall Douglas wrote:
Reentering the COM machinery is definitely not safe, it deadlocks randomly depending on the threading model used.
I have found that if you preload the COM object and precall all the functions you'll call from the async handler, you preexecute all the delay loading and lazy binding code. When the async handler is called, it will then not reenter the COM machinery, thus avoiding deadlocks.
This is not COM, but the loader lock. If you try to load a DLL from DllMain, it deadlocks. This in C++ terms means that constructors of static objects in a DLL can't load DLLs, so in our case, would not be able to resolve stack traces. This is an acceptable limitation.
That said, I'm actually not sure whether the debug engine is in-process.
The bad thing is that any printf like function, kernel calls (including multithreading) or malloc are not async signal handler safe. I'm quite sure that COM functions allocate memory and do some synchronization. It is possible to make an async-signal-safe stacktrace printing on Linux... But on Windows it seems impossible. If anyone knows a way to move data from signal handler into a usual environment I can create a safe_print() function that * will do safe printing for Linux/POSIX * will do some extremely heavy machinery of moving the stacktrace outside the signal handler and printing it for windows. Any ideas on how to do that? -- Best regards, Antony Polukhin