Problem with SqLite and Qt

[ad5xj]

Environment:
SUSE 10.2 KDE 3.5.5 Qt 3.3 Qt Designer and KDevelop
Here is snippets from my Main Form:

mainform.h
#include <qsqldatabase.h>
#include "connection.h"

class QSqlDatabase
----------------------
mainform.cpp
#include <qsqldatabase.h>

public
QSqlDatabase * DB;
----------------------
mainform.ui.h
bool MainWindow:penDB()
try
{
DB->isOpenError();
}
catch(...)
{
qWarning( "Failed to open database: " + DB->lastError().driverText() );
qWarning( DB->lastError().databaseText() );
return false;
};
---------------------
The above situation produces a segmentation fault on execution of any DB member function. The debugger shows a pointer handle for the DB object but expanding the members indicates an incomplete type message.

sqlite from the command line executes without error for any DDL or DML statement.

What am I missing?

[wysota]

1. Qt doesn't throw any exceptions
2. Have you initialized that DB pointer?

[ad5xj]

I did. It is initialized in the connection.h as per the example. It is good to know that Qt does not throw exceptions. How then do you trap such things as segmentation faults and such?

[jacek]

I did. It is initialized in the connection.h as per the example.

Could you post that code?

How then do you trap such things as segmentation faults and such?

You can't trap segmentation faults. OS rules are simple. You can't simply say: "I'm sorry for writing someone's else memory. It won't happen again.". There's only one penalty for a process that violates memory protection --- termination.

All you can do in such case is a post mortem analysis in a debugger.

[ad5xj]

Here is the relevant code from connection.h:

#ifndef CONNECTION_H
#define CONNECTION_H

#include <QMessageBox>
#include <QSqlDatabase>
#include <QSqlError>
#include <QSqlQuery>

static bool createConnection()
{
QSqlDatabase * DB = QSqlDatabase::addDatabase("QSQLITE");
db.setDatabaseName("DBName");
return true;
}

#endif

[jacek]

Here is the relevant code from connection.h:

First of all you shouldn't put code in .h files --- only declarations.

QSqlDatabase * DB = QSqlDatabase::addDatabase("QSQLITE");

Here you declare a new local variable DB, which has nothing to do (except for the name) with the DB variable from your previous post.

db.setDatabaseName("DBName");

Does this even compile? Note that variable names are case sensitive, so there's a difference between db and DB.

[wysota]

You can't trap segmentation faults. OS rules are simple. You can't simply say: "I'm sorry for writing someone's else memory. It won't happen again.". There's only one penalty for a process that violates memory protection --- termination.

Actually you can. You can't trap SIGKILL and SIGSTOP, but SIGSEGV is interceptable. Of course it's not always safe to continue afterwards.

[jacek]

Actually you can.

In theory yes, but not in practice. You intercept SIGSEGV and then what? All you can do is to do some cleanup/logging and exit. You won't know why the signal was sent. You can't be sure if your data is still intact and even whether the stack is valid.

[ad5xj]

Ok I get that you can't trap some errors.

The problem I have is that this is code and structure is from the examples in Qt supplied by Trolltech. There are very few if any other examples to go by. The Tables example works great in Qt4 on XP but my problem is getting it to work on SUSE 10.2.

I tried moving the connection creation code to the main form but the same thing happens.

I am not seeing something, and I don't know what I don't know about SQLite and the Qt database classes in order to make this work.

[wysota]

In theory yes, but not in practice. You intercept SIGSEGV and then what?

It depends what happened and what your app does.

All you can do is to do some cleanup/logging and exit.

True, but sometimes it's all you need. Flushing all unsaved data might be crucial.

You won't know why the signal was sent.

Yes, but sometimes you can deduce that information if you know your app tends to crash in a specific part of the code. Ability to intercept the signal might save your butt sometimes.

You can't be sure if your data is still intact and even whether the stack is valid.

If all you need is to clean up (and you shouldn't try to do anything more), the stack doesn't have to be valid - you'll be pushing to the stack, not popping from it.

[jacek]

The Tables example works great in Qt4 on XP but my problem is getting it to work on SUSE 10.2.

If it works on XP, then it should work on SUSE without any changes in the source code (provided that your application uses only Qt). Maybe the SQLite plugin is missing?

Is libqsqlite.so plugin installed on your system?

[jacek]

It depends what happened and what your app does.

But you have just agreed with me that you can't really tell what happened.

if you know your app tends to crash in a specific part of the code.

If my app tends to crash, I debug it to fix the crash.

If all you need is to clean up (and you shouldn't try to do anything more),

It's good that you agree with me that clean up and termination (instead of fix and continuation) is the only option in the event of SIGSEGV.

the stack doesn't have to be valid - you'll be pushing to the stack, not popping from it.

Remember that the data you want to save might be on that stack.

[wysota]

But you have just agreed with me that you can't really tell what happened.

It doesn't mean you can't guess in what part of code you are. For example you might track the state of the application. I can imagine you might trap SIGSEGV to try to recover from a problem when using an unknown and assumed dangerous external code (like a plugin or so).

If my app tends to crash, I debug it to fix the crash.

Provided you have time and manage to isolate the problem.

It's good that you agree with me that clean up and termination (instead of fix and continuation) is the only option in the event of SIGSEGV.

Now that I think of it... no I just remembered that when you use mprotect, access to a protected region of memory causes a segfault, but the app is perfectly fine, so you can easily recover and continue. There is a chance it's not a sole case.

Remember that the data you want to save might be on that stack.

Yes, or you might be running a system that doesn't handle signals or find dozens of other cases where it won't work.

[ad5xj]

All of this discussion about error trapping is nice and very interesting but it does not tell me why the application gives me the segmentation fault. Please try to stay on point as I am very new at C++ and Qt and it can become very confusing very quickly for me. I am not a veteran C programmer (hense the newbie forum questions).

I do have the sqlite plugin. It came as I installed SUSE 10.2 development distro, otherwise I would not have been able to run sqlite from the command line.

I just noticed that the debugger flashes a notice on the status line that there was a shared library event - if that helps any. I also notice that the database object is defined twice. Once as a mainwindow member and again independently. What is that all about? DB is ONLY a mainwindow public member and the createConnection() is in the Mainwindow code. It should not have created a new object independent of mainwindow.

[wysota]

I do have the sqlite plugin. It came as I installed SUSE 10.2 development distro, otherwise I would not have been able to run sqlite from the command line.

Wrong. You're mixing sqlite library and qsqlite Qt plugin. Jacek was asking about the latter. Please list the content of your plugins/sqldrivers subdirectory of the Qt root install directory.

I also notice that the database object is defined twice. Once as a mainwindow member and again independently. What is that all about? DB is ONLY a mainwindow public member and the createConnection() is in the Mainwindow code. It should not have created a new object independent of mainwindow.

Jacek has already pointed that out in one of his previous posts - you declare a local variable, thus the pointer declared in the main window is still invalid - that's the reason of your segmentation fault.

[jacek]

It doesn't mean you can't guess in what part of code you are.

Yes, you can guess. Guess is a very good word here.

Provided you have time and manage to isolate the problem.

So instead, you prefer to spend time on covering up the failure and trying to fix the errors it has caused using an unreliable mechanism, right? I prefer the fail-fast strategy.

Now that I think of it... no

Too bad that you have changed your mind. Again.

I just remembered that when you use mprotect, access to a protected region of memory causes a segfault, but the app is perfectly fine, so you can easily recover and continue. There is a chance it's not a sole case.

First you give an example, then you write about my example:

Yes, or you might be running a system that doesn't handle signals or find dozens of other cases where it won't work.

I see the pot is calling the kettle black.

[ad5xj]

Ok here is what I have

/usr/lib/qt3(or qt4)/plugins/sqldrivers:

libsqlite.so
libsqlmysql.so
libqsqlodbc.so
libqsqlpsql.so

This appears to be the shared library plugins for SQLite, MySQL, ODBC, and Postgress.

[jacek]

DB is ONLY a mainwindow public member and the createConnection() is in the Mainwindow code.

No, it's not. Look:

static bool createConnection()
{
   ...
}

static bool createConnection()
{
   ...
}

To copy to clipboard, switch view to plain text mode 

createConnection() is a static function, so it's not a method of Mainwindow class, even if it ends up in the same file.

The second problem is that you do have two DB variables:

QSqlDatabase * DB = QSqlDatabase::addDatabase("QSQLITE");

QSqlDatabase * DB = QSqlDatabase::addDatabase("QSQLITE");

To copy to clipboard, switch view to plain text mode 

In this line the "QSqlDatabase * DB" part means "declare a new local variable named DB of QSqlDatabase * type". It should be:

pointerToMainwindow->DB = QSqlDatabase::addDatabase("QSQLITE");

pointerToMainwindow->DB = QSqlDatabase::addDatabase("QSQLITE");

To copy to clipboard, switch view to plain text mode 

Although you should rather make createConnection() a method of Mainwindow class, if openDB() is already there.

But before you change your code further, make sure that Qt is configured correctly on your system. If everything is OK with your system, the sqlbrowser demo should list "QSQLITE" driver in Driver combo box in Connect dialog window.

[ad5xj]

Thanks very much for the clarification. I can see now how it happened. I did change my code and it did eliminate the double definitions.

However I still get a program stop due to some event in the shared library (unexplained by debug messages) on the addDatabase call.

[wysota]

So instead, you prefer to spend time on covering up the failure and trying to fix the errors it has caused using an unreliable mechanism, right? I prefer the fail-fast strategy.

If I have to perform some time intensive experiments and I'm short on time, so I know that I can barely make it with a non-crashing app, then I prefer it to crash now and then if I can continue the experiment without losing the already gathered data instead of debugging the application potentially for hours (remember the bug in the proxy model that caused you so much trouble?)

Too bad that you have changed your mind. Again.

I don't know what makes you think I changed my mind. I just remembered a real and useful example of trapping SIGSEGV where you can safely continue execution. If the app is broken, it's not safe to continue, but not every SIGSEGV means the app is broken.

First you give an example, then you write about my example:

I give you an example that there exists a possibility of using the approach and you counter with an argument that it might not always be possible to use it. I never said it was the UniversalWayOfDoingThings(TM).

I see the pot is calling the kettle black.

I'm afraid I don't know that phrase...

However I still get a program stop due to some event in the shared library (unexplained by debug messages) on the addDatabase call.

That's perfectly normal when using a debugger. Just continue execution.