Originally Posted by
jacek
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.
Originally Posted by
jacek
Could you post the code of MainWindow::createConnection()?
And the range of line numbers, please.
Re: Problem with SqLite and Qt
Reply With Quote
What's inside mainwindow.ui.h:355?
Bookmarks