BreakPad and Windows Qt App event loop

[Ludek Vodicka]

Hello there, 

I integrated Google Breakpad to my multiplatform application working on Windows, Linux and Mac. Everything works fine when I run console application.

But when I run GUI application with Qt event loop, breakpad doesn't work in Windows environment. 

Linux and MacOS works fine - when crash occur, breakpad catch crash, store .dmp and execute my external Crash reporter. But on Windows, default Windows handler is executed "Application has stopped working, Windows is checking for a solution to the problem....".

It seems that Qt somewhere override breakpad handler, but I can't find where. I tried to install handler immediately before the simulated crash, but crash isn't catch too. I tried to search for SetUnhandledExceptionFilter in Qt code, but without success.

Thanks for any advice.

Ludek 

[Ludek Vodicka]

I made some next research and found that UnhandledExceptionFilter is correctly set also in the Event loop, so problem must be somewhere else.

When I try following:

LPTOP_LEVEL_EXCEPTION_FILTER filter = SetUnhandledExceptionFilter(NULL);
delete reinterpret_cast<QString*>(0xFEE1DEAD);

FIter is correctly set up to 

filter = 0x000000013f6496ab google_breakpad::ExceptionHandler::HandleException(struct _EXCEPTION_POINTERS * ptr64) 

Dne neděle, 2. září 2012 17:42:14 UTC+2 Ludek Vodicka napsal(a):

[Ludek Vodicka]

After next searching I found that this problem occurs only on 64-bit windows. On 32-bit everything works ok too.

Dne neděle, 2. září 2012 17:42:14 UTC+2 Ludek Vodicka napsal(a):

Hello there, 

[gemmell]

You mean 32bit Qt on 64bit Windows? I have been running it and it's been catching my exceptions. Haven't tried it with 64bit Qt.

[Luděk Vodička]

It's 64bit Qt on 64bit Windows. After some more searching we found that this issue happened only on some computers. No matter if computer have installed development tools or not.

We didn't find any pattern why this function somewhere works and elsewhere don't.

L.

2012/9/14 gemmell <simong...@gmail.com>

--
You received this message because you are subscribed to the Google Groups "google-breakpad-discuss" group.

To view this discussion on the web visit https://groups.google.com/d/msg/google-breakpad-discuss/-/rjMq13KXlvMJ.

To post to this group, send email to google-brea...@googlegroups.com.
To unsubscribe from this group, send email to google-breakpad-d...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-breakpad-discuss?hl=en.

[gemmell]

Could be unrelated, but I just found this post: 

http://stackoverflow.com/questions/11350801/why-does-google-breakpad-not-handle-all-crashes-how-can-i-debug-these-cases 

[Luděk Vodička]

Thank you fo reply. Unfortunately this isn't our case. Exception handler works correctly on 32-bit app and doesn't catch any exception on 64-bit app.

We also test if SetUnhandledExceptionFilder is correctly set immediately before simulated crash and everything seems ok.

L.

2012/9/14 gemmell <simong...@gmail.com>

--
You received this message because you are subscribed to the Google Groups "google-breakpad-discuss" group.

To view this discussion on the web visit https://groups.google.com/d/msg/google-breakpad-discuss/-/KoYfkirv7bwJ.

[Bruce Dawson]

I suspect you are hitting a 'feature' (i.e.; bug) of 64-bit Windows. When an exception occurs during a kernel callback in 64-bit Windows the OS cannot throw the exception back across the kernel boundary. In order to "maintain reliability" Microsoft made the decision to *silently*swallow*the*exception. When that doesn't work the application just dies.

 

You may think that you are running code in kernel callbacks, but every WindowProc counts as a kernel callback, so you are actually running a *lot* of code in kernel callbacks.

 

You can find more details about this and related issues here:

http://randomascii.wordpress.com/2012/07/05/when-even-crashing-doesnt-work/

 

Luckily there is a way to override this behavior and ensure that your unhandled exception handler is called.

 

When I wrote this blog post I was particularly distressed by the behavior of the malloc/crash/free pattern in the WindowProc. It's amazing to watch it repeatedly leak memory as the crash is silently ignored. What could possibly go wrong?

[Ludek Vodicka]

Hello Bruce,

thank you for your reply!  

I take a quick look to your article and it seems very good. I will take a deeper look to your article as soon as I have some free time. But if this fixes also our bug, it enables us to deliver also 64-bit version! 

It's really sad that MS does things like this in kernel ;-( I spent about week or two with searching for a solution anywhere on web, trying several machines and looking for a pattern why sometimes handler is executed and sometimes it isn't, unfortunately without success. Now your reply gives us hope ;-)

Regards

Ludek

Dne čtvrtek, 10. ledna 2013 20:31:53 UTC+1 Bruce Dawson napsal(a):