Information about multiple threads and exchndl requested about drmingw HOT 11 CLOSED

I'm afraid ExcHnd only supports one thread at this moment.

This is due to how SetUnhandledExceptionFilter() works, and I'm not sure if there's a good way to call SetUnhandledExceptionFilter on every thread. It might be possible to somehow get SetUnhandledExceptionFilter() called on every thread, but I don't have the time (or personal need) to pursuing that.

If you do

LoadLibrary("exchndl.dll");
pfnExcHndlInit = GetProcAddress("ExcHndlInit");
pfnExcHndlInit()

then only the thread where ExcHndlInit() is called will report uncaught exceptions.

It should report any uncaught exception. Not just segfaults.

But you're right, multi-threading is an important question. I'll update the README file to explain this.

from drmingw.

DllMain is called with DLL_THREAD_ATTACH on every new threads after the DLL has been loaded, perhaps it can be used? Obviously this doesn't handle threads created before loading the DLL and you'll have to keep a record of thread IDs for cleaning up on DLL_THREAD_DETACH (a simple linked list should be fine though) but it would be an improvement.

from drmingw.

Yes, hooking DLL_THREAD_ATTACH would be better than nothing.

from drmingw.

Yes, hooking DLL_THREAD_ATTACH would be better than nothing.

Is there a solution to this requirement now？

from drmingw.

Hi @jrfonseca, I'd like to ask for informations

This is due to how SetUnhandledExceptionFilter() works, and I'm not sure if there's a good way to call SetUnhandledExceptionFilter on every thread. It might be possible to somehow get SetUnhandledExceptionFilter() called on every thread, but I don't have the time (or personal need) to pursuing that.

the documentation for SetUnhandledExceptionFilter says that it works globally for all threads. Can you give more insights as to what can be done to make dr. mingw work for all threads? Thank you very much!

from drmingw.

the documentation for SetUnhandledExceptionFilter says that it works globally for all threads

Indeed SetUnhandledExceptionFilter reference does say that Issuing SetUnhandledExceptionFilter replaces the existing top-level exception filter for all existing and all future threads in the calling process.

But my memory is that it doesn't work like that. SetUnhandledExceptionFilter is what exchndl uses, so if it did replace the unhandled exception filter across all threads, then the symptoms @acidtonic reported at the beginning of this issue could not arise.

That said, it's possible my memory is wrong, and there's some external factor interfering with SetUnhandledExceptionFilter behavior in @acidtonic's case.

I googled, but couldn't find conclusive evidence either way.

Best way to know for sure would be to write a test.

One way or the other, SetUnhandledExceptionFilter is the only tool available I know. AddVectoredExceptionHandler is sure to be called on every exception, but there's no telling if it will be handled subsequently or not.

from drmingw.

Yes, hooking DLL_THREAD_ATTACH would be better than nothing.

If I remember correctly, debuggers such as GDB handles every DLL_THREAD_ATTACH event. So, I'm not sure how complex and difficulty does ExcHndl.dll need to do to support this? Just call the necessary SetUnhandledExceptionFilter() function call on each thread?

from drmingw.

I don't know why I made the comment re DLL_THREAD_ATTACH before, because now that I think about it, I recall seeing plenty of bug reports with crash backtraces that happened inside worker threads. This can only mean that exchndl does already handle multiple threads.

from drmingw.

I don't know why I made the comment re DLL_THREAD_ATTACH before, because now that I think about it, I recall seeing plenty of bug reports with crash backtraces that happened inside worker threads. This can only mean that exchndl does already handle multiple threads.

For my experiment here: #71 (comment)
it can catch the crash in a worker thread.

But in other cases, it can't catch the crash in the worker thread, see the first post in issue #71.

from drmingw.

is there any function that I could call manually to write the report file when catching a type of '...' exception, I need more stack information, because it was no use, i still don't know where the exception uccurred.

from drmingw.

is there any function that I could call manually to write the report file when catching a type of '...' exception, I need more stack information, because it was no use, i still don't know where the exception uccurred.

Yes, @UniCd , you could call DebugBreak. It should trigger the report generation.

from drmingw.