QSqlDatabase open() crashes when db cannot be accessed ?

Christian Ehrlicher

@SGaist said in QSqlDatabase open() crashes when db cannot be accessed ?:

I think the point here is that open should cleanly fail and not trigger an application crash.

It does not crash here with psql - the backtrace would be interesting.

R-P-H

@Christian-Ehrlicher said in QSqlDatabase open() crashes when db cannot be accessed ?:

@SGaist said in QSqlDatabase open() crashes when db cannot be accessed ?:

I think the point here is that open should cleanly fail and not trigger an application crash.

It does not crash here with psql - the backtrace would be interesting.

Hi, how can I get that ?

SGaist

Start your application in debug mode and you'll have it when it crashes through the debugger.

R-P-H

@SGaist said in QSqlDatabase open() crashes when db cannot be accessed ?:

Start your application in debug mode and you'll have it when it crashes through the debugger.

Ok, so very interesting, when I run the application in Debug mode it works as expected and does not crash...

Cobra91151

@R-P-H

Add the code below to the main.cpp file and try to run this code in both Debug and Release modes:

   qputenv("QT_FATAL_WARNINGS", "1");
   qSetMessagePattern("Type: %{type}\nProduct Name: %{appname}\nFile: %{file}\nLine: %{line}\nMethod: %{function}\nThreadID: %{threadid}\nThreadPtr: %{qthreadptr}\nMessage: %{message}");

It should print some info about this crash issue.

R-P-H

@Cobra91151 said in QSqlDatabase open() crashes when db cannot be accessed ?:

@R-P-H

Add the code below to the main.cpp file and try to run this code in both Debug and Release modes:
   qputenv("QT_FATAL_WARNINGS", "1");
   qSetMessagePattern("Type: %{type}\nProduct Name: %{appname}\nFile: %{file}\nLine: %{line}\nMethod: %{function}\nThreadID: %{threadid}\nThreadPtr: %{qthreadptr}\nMessage: %{message}");
It should print some info about this crash issue.

Hi, nothing is printed. It is a widget application, not a console app if that's why ?

Cobra91151

@R-P-H

You need to clean, run qmake and rebuild your project. It should display the debug info when the crash occurs in the Application output window.

R-P-H

@Cobra91151 said in QSqlDatabase open() crashes when db cannot be accessed ?:

@R-P-H

You need to clean, run qmake and rebuild your project. It should display the debug info when the crash occurs in the Application output window.

Yes, I did as you said and there is no additional output. I also created a new console project with the same database code and it runs fine. No idea what's wrong with my widget application in release mode...

SGaist

One other thing you can do is set the QT_DEBUG_PLUGINS environment to 1 in the Run part of the Project panel to see if there's something happening there.

Since you talked about a console app working fine, did you try to create a dummy widget project and just do the connection there ?

R-P-H

@SGaist said in QSqlDatabase open() crashes when db cannot be accessed ?:

One other thing you can do is set the QT_DEBUG_PLUGINS environment to 1 in the Run part of the Project panel to see if there's something happening there.

Since you talked about a console app working fine, did you try to create a dummy widget project and just do the connection there ?

I set the environment variable. I get the output from all the plugins on startup but nothing extra when calling open().

I created a fresh widget project and just added the connection part of the code and it works fine. I figure that this means there's some other library included in my original application that may be causing this issue ?

R-P-H

So through much debugging I finally found the issue. Just 1 line of code:

QCoreApplication::processEvents();

I have a thread that runs at application startup and emits an image to a label for displaying. The above line of code was at the end of this loop. Removing the line of code doesn't appear to cause any other issues and solves the segfault when trying to open the database.

Why this causes the segfault in the first place is still bizarre to me...

SGaist

At the end of what loop ?

R-P-H

@SGaist said in QSqlDatabase open() crashes when db cannot be accessed ?:

At the end of what loop ?

It's a thread with a while loop that emits images to another window for display. The thread (with the loop) is running while the database is opened...

SGaist

Some sort of splash screen ?

In any case, it looks like that thread implementation might need a look into it to avoid future issues.

R-P-H

@SGaist said in QSqlDatabase open() crashes when db cannot be accessed ?:

Some sort of splash screen ?

In any case, it looks like that thread implementation might need a look into it to avoid future issues.

No, its a live video. The basic flow is like this:

//On MainWindow Load...
//Database class is created which contains database settings.
//Create thread class and start the thread.
//Thread runs a while() loop that captures an image and emits the image to MainWindow via a signal.
//MainWindow receives the signal with the image and displays it inside a label.

//User clicks a button inside MainWindow...
//Open database using the database class.
//Do something...
//Close database.

I don't really see anything very wrong with the above program flow. Yet having QCoreApplication::processEvents(); inside the loop breaks the database opening. Very strange.

SGaist

The fact that processEvent is called in a thread is usually the sign of something off.

R-P-H

@SGaist said in QSqlDatabase open() crashes when db cannot be accessed ?:

The fact that processEvent is called in a thread is usually the sign of something off.

It was actually being called inside the slot in MainWindow to ensure that the label renders the image. But you are correct, it shouldn't be there. Is there any danger in using it ?

SGaist

I have usually seen processEvent called from the main thread directly which forces processing of events however calling it from a different thread is the first time. As you can see there's some strange interaction. I currently wonder whether you have an event that is processed by the wrong event loop.