I'm using Qt4 with Python 2.6.5 on Ubuntu (Lucid)
I have a function that opens a DB connection using QSqlDatabase:pen, which is segfaulting in some instances. I have been unable to create a simple test case that reproduces it, but it happens every time I run the program, on the fifth time it is called. As far as I can tell, the call and everything about the QSqlDatabase instance are identical and I can't determine what makes it segfault.
def Open( self ):
# self._db is a QSqlDatabase instance
if not self._db.isOpen():
etl.Log( "Opening connection to %s" % ( self.Name ) )
if etl.DebugMode:
print "driverName: %s" % ( self._db.driverName() )
print "hostName: %s" % ( self._db.hostName() )
print "databaseName: %s" % ( self._db.databaseName() )
print "userName: %s" % ( self._db.userName() )
print "password: %s" % ( "*" * len(self._db.password()) )
print "isDriverAvailable: %s" % ( self._db.isDriverAvailable( self._db.driverName() ) )
print "isOpen: %s" % ( self._db.isOpen() )
print "isOpenError: %s" % ( self._db.isOpenError() )
print "isValid: %s" % ( self._db.isValid() )
if not self._db.open():
raise Exception( "Could not open connection to %s" % ( self.Name ) )
The output of which is:
Opening connection to ERP Rollup
driverName: QTDS
hostName: dev-nav01.skinit.loc
databaseName: Demo Database NAV (6-0)
userName: etl
password: ********
isDriverAvailable: True
isOpen: False
isOpenError: False
isValid: True
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff0a1d42b in dblib_add_connection (login=<value optimized out>,
server=<value optimized out>, msdblib=<value optimized out>) at dblib.c:239
239 dblib.c: No such file or directory.
in dblib.c
Using gdb, I find the local vars in dlib.c to be:
i = 0
list_size = 4096
The last couple of lines from the FreeTDS log are:
07:49:34.247604 6159 (token.c:495):tds_process_tokens(0x14e5270, 0x7fffffffd13c, 0x7fffffffd138, 0x100)
07:49:34.247631 6159 (token.c:498):tds_process_tokens() state is COMPLETED
07:49:34.247683 6159 (dblib.c:237):dblib_add_connection(0x7ffff0c695a0, 0x14e5270)
So I also used gdb to check out the values at those memory addresses:
0x7ffff0c695a0 <g_dblib_ctx>: 0x00000000
0x14e5270: 0x00000007
I'm not a C/C++ programmer, so I'm unsure how to proceed, but it looks like it's the NULL pointer causing the problem (though the 0x00000007 is suspicious as well, cause the dblib_add_connection args are both pointers and I wouldn't expect to find a pointer with that low of a memory address).
I really would appreciate any help someone can provide. Also, if anyone can tell me if this is the type of incident that a commercial support license would cover, that might be an avenue I can go down.
Bookmarks