Problem with SqLite and Qt

[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]

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.

[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.

[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.

[ad5xj]

Well I did hit continue and gdb give me this:

Failed to read a valid object file image from memory.

(gdb) backtrace
Stopped due to shared library event
#0 0xb7f0ec70 in _dl_debug_state () from /lib/ld-linux.so.2
#1 0xb7f036f6 in dl_main () from /lib/ld-linux.so.2
#2 0xb7f13e6b in _dl_sysdep_start () from /lib/ld-linux.so.2
#3 0xb7f012c4 in _dl_start () from /lib/ld-linux.so.2
#4 0xb7f008d7 in _start () from /lib/ld-linux.so.2
(gdb) info args
No symbol table info available.
(gdb) info local
No symbol table info available.
(gdb) frame 0
#0 0xb7f0ec70 in _dl_debug_state () from /lib/ld-linux.so.2
(gdb) info args
No symbol table info available.
(gdb) info local
No symbol table info available.
(gdb) continue
[Thread debugging using libthread_db enabled]
[New Thread -1221592864 (LWP 6190)]
Stopped due to shared library event
(gdb) continue
[Switching to Thread -1221592864 (LWP 6190)]
Stopped due to shared library event
(gdb) continue
Stopped due to shared library event
(gdb) continue
Stopped due to shared library event
(gdb) continue
Stopped due to shared library event
(gdb) continue
Stopped due to shared library event
(gdb) continue
Stopped due to shared library event
(gdb) continue
Stopped due to shared library event
(gdb) continue

Breakpoint 1, MainWindow::createConnection (this=0x80d9990) at mainwindow.ui.h:354
/home/ken/NetLogger/mainwindow.ui.h:354:12111:beg:0x806100c
(gdb) info thread
* 1 Thread -1221592864 (LWP 6190) MainWindow::createConnection (this=0x80d9990) at mainwindow.ui.h:354
(gdb) backtrace
#0 MainWindow::createConnection (this=0x80d9990) at mainwindow.ui.h:354
#1 0x08054c10 in MainWindow::init (this=0x80d9990) at mainwindow.ui.h:53
#2 0x0805a7e0 in MainWindow (this=0x80d9990, parent=0x0, name=0x0, fl=1) at mainwindow.cpp:740
#3 0x0804f660 in main (argc=
Cannot access memory at address 0x0

) at main.cpp:21
(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y 0x0806100c in MainWindow::createConnection() at mainwindow.ui.h:354
breakpoint already hit 1 time
(gdb) info args
this = (class MainWindow * const) 0x80d9990
(gdb) info local
No locals.
(gdb) whatis this
type = class MainWindow * const
(gdb) continue
Stopped due to shared library event
(gdb) continue
Stopped due to shared library event
(gdb) continue

Program received signal SIGSEGV, Segmentation fault.
0x0806108a in MainWindow::createConnection (this=0x80d9990) at mainwindow.ui.h:355
/home/ken/NetLogger/mainwindow.ui.h:355:12154:beg:0x806108a
(gdb) info thread
* 1 Thread -1221592864 (LWP 6190) 0x0806108a in MainWindow::createConnection (this=0x80d9990) at mainwindow.ui.h:355
(gdb) backtrace
#0 0x0806108a in MainWindow::createConnection (this=0x80d9990) at mainwindow.ui.h:355
#1 0x08054c10 in MainWindow::init (this=0x80d9990) at mainwindow.ui.h:53
#2 0x0805a7e0 in MainWindow (this=0x80d9990, parent=0x0, name=0x0, fl=1) at mainwindow.cpp:740
#3 0x0804f660 in main (argc=
Cannot access memory at address 0x0

) at main.cpp:21
(gdb) info args
this = (class MainWindow * const) 0x80d9990
(gdb) info local
No locals.
(gdb) step
Couldn't get registers: No such process.
(gdb) info thread
Couldn't get registers: No such process.
(gdb) backtrace
(gdb) Process exited

[wysota]

What exactly should we be looking at? I see you have a segfault What's inside mainwindow.ui.h:355?

[ad5xj]

A call to QSqlDatabase::setDatabasename()

[jacek]

A call to QSqlDatabase::setDatabasename()

Could you post the code of MainWindow::createConnection()?

[wysota]

I believe that a better approach is to save the data before the crash occurs, because you can't trust the memory contents after it.

Yes, of course, provided it is possible. Dumping lots of data to disk (or even ramdisk) takes time. If you can do it in an incremental fashion, it's ok, but otherwise it will slow down the experiment even more. I know you like your apps to be perfect and bug free and I completely agree with you, but sometimes the practical side differs from the theory and it's nice to have a way that can save you in such cases.

Yes, I do remember, even better than you. It had nothing to do with crashes and preserving critical data. Simply a few empty columns were visible in the QTableView.

The point is you wasted a lot of time to find the problem. And the problem wasn't in your code, so fixing it wasn't that easy.

So if you didn't change your mind, you still agree with me, right?

Read my post again.

We already agreed that in case of a SIGSEGV, you can't tell what caused it, so as you said, you can only guess.

No, not in that case. Here you can be pretty certain what happened by tracking the state of the application and performing some checks. And even if you couldn't, if you test your application enough, you can assume the problem doesn't come from somewhere else. And even if you didn't, you can continue and if something is really broken, the segfault will occur again and you can abort the app then.

Consider this snippet:

void somehandler(int){ flag = TRUE; }
//...
signal(SIGSEGV, somehandler);
protected[4] = 7; // sigsegv here
signal(SIGSEGV, SIG_DFL);
if(flag){ ... }

void somehandler(int){ flag = TRUE; }
//...
signal(SIGSEGV, somehandler);
protected[4] = 7; // sigsegv here
signal(SIGSEGV, SIG_DFL);
if(flag){ ... }

To copy to clipboard, switch view to plain text mode 

Here I can pretty well define where the segmentation fault occured and the example can be considered practical - it mimics a try-catch block.

But earlier I've said that the stack might not be valid and you countered it with an argument that it might not always be a problem.

But even earlier I said you can save the data and then you said the data might be on the stack and it might be broken. But I never said anything about saving the data from the stack, I was talking about saving data - some data.

Don't you think you are a bit inconsistent in the way you treat arguments?

I don't see any inconsistencies in my reasoning. I just see you can't admit that trapping SIGSEGV is not only a theoretical possibility. I have given you an example of such use and you still say the same. Maybe the snippet from this post will make you reconsider. Being stubborn in this case won't make your arguments better.

Could you post the code of MainWindow::createConnection()?

And the range of line numbers, please.

[jacek]

Yes, of course, provided it is possible.

Exactly the same thing can be said about your approach --- you can try to dump data after you intercept SIGSEGV, but it might not be possible. If I had to choose between possible decrease of performance and correct data, I would choose correct data.

The point is you wasted a lot of time to find the problem. And the problem wasn't in your code, so fixing it wasn't that easy.

But still it has nothing to do with the subject of this discussion, that is whether it is practical or not to recover from faults that caused SIGSEGV.

you can continue and if something is really broken, the segfault will occur again and you can abort the app then.

By that time your application could do something nasty. What if the SIGSEGV was caused by a buffer overflow? IMO fail-fast is much safer approach.

Here I can pretty well define where the segmentation fault occured and the example can be considered practical - it mimics a try-catch block.

I wouldn't call such abuse a practical example. Anyway, yes, you can provoke a segmentation fault and continue execution, but you are dragging this discussion away from where it started --- recovery from memory faults.

But even earlier I said you can save the data and then you said the data might be on the stack and it might be broken. But I never said anything about saving the data from the stack, I was talking about saving data - some data.

I'm afraid you failed to see the forest behind the trees. What I tried to show you is that you rebuke my arguments, yet at the same time you use exactly the same kind of argumentation to support your point. That's what I call an inconsistency.

Being stubborn in this case won't make your arguments better.

If you are going to step further into using ad hominem arguments, let's better simply agree that:

1. my point is that it's impractical to recover from memory faults and continue execution after receiving SIGSEGV, because you can't be sure about the state of the memory and what caused the signal to be emitted,
2. you don't agree with me.

[jacek]

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

I believe that a better approach is to save the data before the crash occurs, because you can't trust the memory contents after it.

remember the bug in the proxy model that caused you so much trouble?

Yes, I do remember, even better than you. It had nothing to do with crashes and preserving critical data. Simply a few empty columns were visible in the QTableView.

I don't know what makes you think I changed my mind.

So if you didn't change your mind, you still agree with me, right?

If the app is broken, it's not safe to continue, but not every SIGSEGV means the app is broken.

We already agreed that in case of a SIGSEGV, you can't tell what caused it, so as you said, you can only guess.

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.

But earlier I've said that the stack might not be valid and you countered it with an argument that it might not always be a problem.

Don't you think you are a bit inconsistent in the way you treat arguments?