Fatal exception handling

[Big Muscle]

Hello, I'm continuing with the migration from WTL to wxWidgets. I use wx SVN now and I have some question related to fatal exception handling.

In Win32 code, we were using SetUnhandledExceptionFilter function. It set fatal exception handler for whole application, i.e. all its threads.

In WX code, I use wxHandleFatalExceptions and override OnFatalException function. Everything works correct except some things:

a) When "threaded" classes are NOT derived from wxThread then fatal exceptions are not handled by WX handler. We use different thread library and we can't use wxThread. Is there any solution to handle fatal exceptions from secondary threads which are not derived from wxThread?

b) When fatal exception handler is installed, then fatal exceptions are caught always, also when running in debugger. Is there any solution that WX handler will be used only when not running in debugger? (It means that debugger will always break the execution and shows up where it crashed.)

Thank you.

[doublemax]

You may be wandering on uncharted terrain here

All i can say is that i never dealt with this topic in wxWidgets, and my guess is that not too many users have.

If you don't get help here, try posting on the wx-users mailing list, where the wx developers might have an answer.
http://www.wxwidgets.org/support/maillst2.htm#users

[Auria]

I don't have any magical solution in either case; regarding non-wx thread, I guess the only way I see is

Code: Select all

// whatever your thread entry is
void thread_entry_function()
{
  try
  {
    // thread stuff ...
  }
  catch (...)
  {
     // handle exception (pass it to your exception handler?)
  }
}

about debugger, a "classical" solution is to define DEBUG=1 in debug mode and NDEBUG=1 in release mode; then you can install a different exception handler when DEBUG=1

[Big Muscle]

My original topic is one year old but I use it again now...

I solved the problem with using SetUnhandledExceptionFilter under MSW and wxHandleFatalException(true) under other OS's (it handles exceptions in worker threads on Ubuntu correctly). But now I have problem when I want to display error message to user. I generate crash report and then want to display messagebox "App crashed. Crashlog has been generated in folder xxxx. Please, send it to developers" and then exit the application. This is ok when crash occurs in main (GUI) thread but I can't use wxMessageBox from worker threads - it simply doesn't work.

I don't see a good way to pass through event queue and display messagebox in main thread, because application needs to be closed immediately when function OnFatalException() ends.

Is there any solution for my problem?

[evstevemd]

but I can't use wxMessageBox from worker threads - it simply doesn't work.

I don't see a good way to pass through event queue and display messagebox in main thread, because application needs to be closed immediately when function OnFatalException() ends.

Is there any solution for my problem?

I will throw my suggestion. First, don't use any gui function in worker threads. Put them in main thread.
In this case of yours, I would not terminate main app on secondary thread. i will put my OnFatalException on primary thread and use it to catch custom fatal event. Than each time I catch such exception I will post the event to main thread and method will react and close app, evven display fancy messages. That way you can send logs via event if you want.
Just how I would do it, may be there is better and simpler way!

[Auria]

You can check http://wiki.wxwidgets.org/Inter-Thread_ ... ain_thread for how to communicate with the main thread using wxWidgets events. Using GUI controls/dialogs from threads is not supported, so whenever a thread of yours needs to do something GUI related, queue an event and let the main thread do it

[Big Muscle]

I know how to communicate with main thread, but I don't think it's good idea to do it from fatal exception handler.

[evstevemd]

I know how to communicate with main thread, but I don't think it's good idea to do it from fatal exception handler.

I'm interested to know why it is not a good Idea!

[Auria]

If the exception is so fatal that the main thread can't even receive events anymore, then I'm sorry, there's nothing you can do to recover from it

[Big Muscle]

I know how to communicate with main thread, but I don't think it's good idea to do it from fatal exception handler.

I'm interested to know why it is not a good Idea!

You can imagine, for example, such situation when worker thread crashes in critical section which main thread is waiting for.

[RainRat]

I know how to communicate with main thread, but I don't think it's good idea to do it from fatal exception handler.

I'm interested to know why it is not a good Idea!

You can imagine, for example, such situation when worker thread crashes in critical section which main thread is waiting for.

If you use classes like wxCriticalSectionLocker the destructor will automatically be invoked (releasing the critical section) during stack unwinding when an exception is throw, so your main thread will not hang.

My thought is that you can catch the exception at the top level of your thread, send an event to the main thread, then exit the thread.

[Big Muscle]

Of course, critical section can be released (although I'm not sure whether it happens in case of SetUnhandledExceptionFilter), but the critical section is there for some reason -> main thread is not blocked and continues its execution, but since the critical section in other thread was not processed correctly (it was unexpectedly interrupted), the behavior of main thread is nondeterministic since now. So you can't even say whether it gets to event queue processing (it can crash somewhere, it can hang somewhere else, it can write invalid data etc.)

[Auria]

If the main thread hanged, then sorry there is nothing you can do to update the GUI.

[evstevemd]

main thread is not blocked and continues its execution, but since the critical section in other thread was not processed correctly (it was unexpectedly interrupted), the behavior of main thread is nondeterministic since now.

As rainrat said, make your own type of event that will alert the main thread that critical section was not handled correctly which will stop app from using wrong data or if that data is critical to workings of app then save data and exit the app

[doublemax]

Under Windows you could use the Win32 ::MessageBox(). I'd guess this works even inside an exception handler.
I don't know about other platforms.

As a last resort, if all you want to do is display a message, maybe you could launch a small helper application that ships with your program. Not very elegant, but probaby works on all platforms.