Simple code causes segmentation fault...in debug

[Raccoon29]

Hello everyone,

following code seems trivial to me:


QSqlDatabase db=QSqlDatabase::addDatabase("QMYSQL","connection");
db.setHostName("localhost");
db.setDatabaseName("dbname");
db.setUserName("user");
db.setPassword("secret");
db.open();

QSqlQuery query(db);
query.prepare("SELECT col FROM table");
query.exec();
query.next();

db.close();
QMessageBox::information(this,"DEBUG","Done");

anyway if executed in debug, it makes the application raise a segmenetation fault when closed, while in release everything works fine.

If you destroy explictly the QSqlQuery object (allocating it dinamically or closing its code in { } braces if a stack object), everything works fine in debug too. Conflict?

Try it yourself, behaves in the same way to you?

Environment:
OS: windows Xp SP3
Qt: 4.3.0
QtCreator: 1.1.1
driver: libmysql4.dll / libmysqld4.dll
patient: full
luck: n/d
ideas: over

My issue? Qt issue? Driver issue? Destiny issue?

Thanks in advance right to you reading!

[gmaa45]

must be prepare mysql driver
the mysql not default driver,

see http://doc.trolltech.com/4.5/sql-driver.html

[Raccoon29]

must be prepare mysql driver
the mysql not default driver,

see http://doc.trolltech.com/4.5/sql-driver.html

Sorry, I don't get it.
What do you mean? If you meant to tell me how to build the driver, that's not needed: I built it already and is able to query the database.

[faldzip]

and where did you add those braces { } which make this code work?

[wysota]

I'd say it's a normal thing to get a warning (but not a segfault). If QSqlQuery object is still alive while the database connection is removed, Qt complains about it. But should definitely not crash.

[Raccoon29]

and where did you add those braces { } which make this code work?
like this:


QSqlDatabase db=QSqlDatabase::addDatabase("QMYSQL","connection");
db.setHostName("localhost");
db.setDatabaseName("dbname");
db.setUserName("user");
db.setPassword("secret");
db.open();

{
QSqlQuery query(db);
query.prepare("SELECT col FROM table");
query.exec();
query.next();
}

db.close();
QMessageBox::information(this,"DEBUG","Done");


I'd say it's a normal thing to get a warning (but not a segfault). If QSqlQuery object is still alive while the database connection is removed, Qt complains about it. But should definitely not crash.
So I guess to you this code works?

By the way, when segfaults output complains:


HEAP[temp.exe]:
HEAP: Free Heap block 52b3e88 modified at 52b3ee4 after it was freed

and stack-trace shows:


0 ntdll!DbgUiConnectToDbg C:\\WINDOWS\\system32\tdll.dll 0 1 ntdll!RtlpNtMakeTemporaryKey C:\\WINDOWS\\system32\tdll.dll 0
2 ntdll!LdrFindEntryForAddress C:\\WINDOWS\\system32\tdll.dll 0
3 ?? 0
4 ?? 0
5 ?? 0
6 ?? 0

mumble mumble...

[wysota]

The code is too generic to try it, but it should work. Could you try running this program to see if it crashes too?


#include <QtDebug>
int main(){
qDebug() << "XXX";
return 0;
}

It seems you are having a problem with debugging, not with your application.

[Raccoon29]

The code is too generic to try it, but it should work.
Well, this is all the application is made of, after a lot of debug reduction, I got this simple code that make blow up everything.


Could you try running this program to see if it crashes too?
No, it doesn't (neither outputs anything).


It seems you are having a problem with debugging, not with your application.
But sounds strange that that code is required to have problems...isn't it?
Just an idea: could it be the mysql driver somehow? (corruption and so on)

[wysota]

It seems that's a windows dll that's failing. But the question is what is causing it. As for my test app, add CONFIG+=console to the project.

[Raccoon29]

It seems that's a windows dll that's failing.
I see: my system is slowly and painfully dieing... :(

But the question is what is causing it.
I'm sweating here... if you get any clue or test about this, I'll try.

Meanwhile thank you for all :)

[Raccoon29]

UPDATE:

I found another analog situation:


QSqlQuery query(db->Handle()); //Handle() returns QSqlDatabase preset
if(db->Connect()) //connection of same object of Handle()
{
query.prepare("SELECT something FROM somewhere"); //segfault!
...
}

In short, in this situation it segfaults because I create QSqlQuery object before the connection is opened.
Ok, that's bad, also documentation says that. But isn't segmentation fault a bit excessive??
I mean, a warning within an undefined behavior would be enhough, and probably it is in a normal environment...

Further more, trying to query a "USE db" command messes up everything, explosions everywhere.

I fear that here is something heavy happening... I would like to use a "sure-working" mysql driver to know at least if that's the reason or not, but where to take it?

[wysota]

I'm pretty convinced this is not related to the database but to the fact that your program crashes at a moment when Qt tries to issue a warning to the console.

[Raccoon29]

In release I went ahead and program works, but this debug not working...
I compiled with QT += warn_off but I got the same problem: is this a relevant test or I missed the point?

[wysota]

You missed the point :)

[Raccoon29]

Owned, lol :D

I'm just ignoring debug since release works, if in the future this problem shall show up again... I'll invent something.

Thank youuuuu

EDIT: not QT+=warn_off, but CONFIG+=qt debug warn_off

[Raccoon29]

I got it to work and I found the reason of everything.

Solution was in documentation:

Warning: You must load the SQL driver and open the connection before a QSqlQuery is created. Also, the connection must remain open while the query exists; otherwise, the behavior of QSqlQuery is undefined.
in fact I was closing the connection while the related QSqlQuery was still alive, thus "undefined behavior" -> exception; this explains the { } braces trick too.

Eventually somehow the exception was related to mysql driver, because the same code works with sqlite driver, maybe some different internal management, who knows...

Anyway the problem is solved, thanks to everyone and first of all to S.wysota!

[wysota]

in fact I was closing the connection while the related QSqlQuery was still alive, thus "undefined behavior" -> exception; this explains the { } braces trick too.
But you should get a warning and not a crash. Unless of course you are trying to actually access the query later on.

[tangential]

The problem is that mysql doesn't check pointers before dereferencing them (which is what those handles are). The code is cleaned up for 4.6, but yeah, if you do out of the ordinary things, then out of the ordinary things are bound to happen (in mysql's case, segfault :/)

[Raccoon29]

But you should get a warning and not a crash.
As you suggested, maybe actually a warning that pops up in a bad moment makes it crash, this had to happen just in debug, in release no problem.

if you do out of the ordinary things, then out of the ordinary things are bound to happen (in mysql's case, segfault :/)
...and out of ordinary headhaches are provided. :)