Re: [boost] [Stacktrace] review, please stop discussing non-Stacktrace issues

Subject: Re: [boost] [Stacktrace] review, please stop discussing non-Stacktrace issues
From: Antony Polukhin (antoshkka_at_[hidden])
Date: 2016-12-18 12:08:11

2016-12-18 17:03 GMT+03:00 Peter Dimov <lists_at_[hidden]>:
> 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