[RDP] Shooting myself in the foot with RDSqlQuery again

Fred Gleason fredg at paravelsystems.com
Fri Oct 26 13:02:42 EDT 2007


Howdy Folks:

I've been investigating some seemingly random segfaults in certain modules 
(RDLibrary and RDAirPlay in particular) and have discovered a scenario where 
a side effect of our shiny new DB reconnect feature is the escalation of a 
'minor' failure into a crash.

Consider the following.  At program startup, we initialize the database 
connection:

*** snip snip ***
QString err="myapp: ";
QSqlDatabase *my_db=RDInitDb(&err);
*** snip snip ***

then, at some later point, we do:

*** snip snip ***
QString sql=<some-bad-sql>;
RDSqlQuery *q=new RDSqlQuery(sql,my_db);
delete q;
[...]
sql=<some-good-sql>;
q=new RDSqlQuery(sql,my_db);  // WHAM-O -- Segfaults here!!
delete q;
*** snip snip ***

It segfaults at the second query execution because the database handle 
('my_db') is no longer valid -- the database reconnect nukes it, but the app 
never finds out about it.

Of course, the real problem here is (once again) the loused-up SQL statement, 
but I'm wondering if in the interests of robustness it might make some sense 
to remove the second argument to the RDSqlQuery() constructor altogether, 
seeing as passing a null value to the underlying QSqlQuery automatically 
'does the right thing' (i.e. uses the 'current' db connection) anyhow.  Dan, 
is there anything in your plans that would require that this parameter be 
retained?  If we do need to retain it, then we need some sort of callback 
mechanism for notifying clients when the handle changes.

Cheers!


|-------------------------------------------------------------------------|
| Frederick F. Gleason, Jr. |               Chief Developer               |
|                           |               Paravel Systems               |
|-------------------------------------------------------------------------|
|      The First Rule of Program Optimization:                            |
|               Don't do it!                                              |
|                                                                         |
|      The Second Rule of Program Optimization (for experts only!):       |
|               Don't do it yet!                                          |
|                                        -- Michael Jackson               |
|-------------------------------------------------------------------------|


More information about the Rivendell-prog mailing list