How to configure Visual Studio to stop on qfatal?

Alain38 0

Hi,
I have a lot of tests (using QTest). Sometimes some of them generate calls to qfatal. Unfortunately, in this case, even whether my test suite is compiled in debug mode, it does not stop to give me the capability to debug. It just kills the application. So, for the moment, the only way I found to debug in this situation is to set breakpoints inside q_assert functions.

Does it exist a way to configure Visual Studio 2017 so that a call to qfatal just block the application for debugging instead of killing it?

JonB

@Alain38-0
You can write your own "qtMessageHandler" and install it via http://doc.qt.io/qt-5/qtglobal.html#qInstallMessageHandler.

See also http://doc.qt.io/qt-5/qtglobal.html#qFatal.

If you are using the default message handler this function will abort to create a core dump. On Windows, for debug builds, this function will report a _CRT_ERROR enabling you to connect a debugger to the application.

So it may be that in Debug build you can already trap just that.

Alain38 0

Hi @JonB,
My purpose is just to be in a mode to be able to debug, so to have the call stack and so on, to be able to understand why I have a problem. Writing my own handler for this seems a little bit to heavy compared to the current solution (setting breackpoints in Qt source files).

JonB

@Alain38-0
You don't write your own code to handle it. You write the function like I said and put a breakpoint in when QtMessageType::QtFatalMsg. Or for that case there is a Windows call to auto-enter a debugger if attached, ::DebugBreak https://msdn.microsoft.com/en-us/library/ms679297(v=VS.85).aspx, to save you even bothering with a breakpoint. In all cases you let your message handler then call the default message handler. Total about 2 lines of code. Or copy the exact example code on the referenced page. As you please.

Having said that the doc I quoted

On Windows, for debug builds, this function will report a _CRT_ERROR enabling you to connect a debugger to the application

implies you should already be able to catch this in the VS debugger without any further work from you, but I leave you to investigate that.

Alain38 0

@JonB The problem is that I am in debug mode. So a debugger is supposed to ba automatically connected to the application. But qFatal is not trapped by the debugger.

JonB

@Alain38-0
This really should not be complicated. You are confusing me now.

Do you compile for Debug? I assume yes.
Do you run your app/tests from inside VS or from outside VS?
If you run from inside VS, do you set it running via "Start Debugging" or "Start without Debugging"?

Alain38 0

@JonB
Everything si compiled in debug mode. I'm running inside VS by using "Start Debugging". This is why I am so surprised that qFatal kill my application instead of just be trapped by the debugger. To add (I have seen something about on Internet), I'm using _DEBUG (and not NDEBUG). So CRT debugging is supposed to be active.

JonB

@Alain38-0
Then you are saying you do not agree with the documentation statement:

On Windows, for debug builds, this function will report a _CRT_ERROR enabling you to connect a debugger to the application

I cannot comment on that. But let's assume you're right. So I'm saying, to workaround for what you want please do the following:

From http://doc.qt.io/qt-5/qtglobal.html#qInstallMessageHandler copy & paste their myMessageOutput() function sample code into your application.
Install that as event handler somewhere via qInstallMessageHandler(myMessageOutput);, as they show in their main().
Place a VS debug breakpoint on case QtFatalMsg: (you may need to place it on the line after the case).
Run your app via "Start Debugging".
Optionally test that, say, an explicit qDebug() of your own does hit the installed handler (breakpoint on entry to function), to make sure all is correctly in place.
Cause a qFatal(), which may be either in your own code or in a Qt library, to get hit.
You should find you stop at the breakpoint, and can see the stacktrace?
Assuming that is working, you can now prune that function's code so that it has little other than a place you can breakpoint for type == QtFatalMsg, and in all cases calls the original handler at the end of the function.

Alain38 0

@JonB IN fact It is not that I do not agree with the documentation. It is just that I have an unexpected behavior. It can come from a lot of reasons. I can have somewhere a strange configuration (quite common with Windows). It might come from the fact I'm under QTest, so not in a normal situation (no running qApp), and so on.

For the moment I'm debugging by setting breakpoints in qGlobal (qt_assert and qt_assert_x). But as I'm managing several VS solutions I have to think to set them on each solution. It is why I hoped that someone already had the same problem.

JonB

@Alain38-0
I have no idea why you choose not to try what I have suggested. Up to you.

Alain38 0

@JonB Do not misunderstand. I have not said that I will not try your solution. I have just explained my temporary approach that I'm currently using to find the origin of my crashes. For the future I will take time to investigate more with the hope to have a generic solution to apply on all my VS solutions.