Subject | Firebird 1.5 segfault |
---|---|
Author | Brad Pepers |
Post date | 2003-10-24T20:42:19Z |
I have a problem with the latest RC6 release of Firebird 1.5. I'm using Linux
and loading the libgds.so library at runtime with dlopen. The application is
also compiled with Qt setup to use threads so it links with qt-mt.so and all
this is on Redhat 9. What is happening is that a segfault happens when I try
to create a company using isc_dsql_execute_immediate. The backtrace I get
shows me the segfault is happening in the ParsedPath::~ParsedPath when it
calls operator delete[]. The operator delete[] it uses comes from the
qt-mt.so library because it redefines it for thread safety concerns I
imagine.
So the question is whether the problem is with Qt redefining operator delete[]
in some bad way or is it with Firebird. Looking at the dir_list.cpp code it
looks like the memory for PathElem is allocated using FB_NEW and some memory
pool mechanism. If so, is it really safe to deallocate that memory using
operator delete[] or shouldn't there be a FB_DELETE? Or is the problem that
the alloc.h inlines operator new[] so that version gets used there but
operator delete[] is not inline so it has to be linked and if there is a
different operator delete[] in one of the other libraries.
Anyway its a problem for anyone who wants to link Firebird in at runtime when
the are using a library that defines its own operator delete[]. Actually the
same problem happens if I give "-lqt-mt -lgds" to the linker though it
doesn't if I instead use "-lgds -lqt-mt". I sure hope there is a way to fix
this since otherwise there is no runtime loading of Firebird!
Here is the backtrace:
#0 0x42074760 in _int_free () from /lib/tls/libc.so.6
#1 0x42073786 in free () from /lib/tls/libc.so.6
#2 0x405c37a3 in operator delete(void*) ()
from /usr/lib/qt-3.1/lib/libqt-mt.so.3
#3 0x405c37cf in operator delete[](void*) ()
from /usr/lib/qt-3.1/lib/libqt-mt.so.3
#4 0x41c3c649 in ParsedPath::~ParsedPath() () from /usr/lib/libgds.so
#5 0x41c40258 in DirectoryList::IsPathInList(Firebird::PathName const&) ()
from /usr/lib/libgds.so
#6 0x41b859fe in ISC_lookup_entrypoint () from /usr/lib/libgds.so
#7 0x41b85681 in ISC_lookup_entrypoint () from /usr/lib/libgds.so
#8 0x41b16d2e in isc_unwind_request () from /usr/lib/libgds.so
#9 0x41b0d407 in isc_attach_database () from /usr/lib/libgds.so
#10 0x41bdd261 in PREPARSE_execute () from /usr/lib/libgds.so
#11 0x41b11303 in isc_dsql_exec_immed2_m () from /usr/lib/libgds.so
#12 0x41b11025 in isc_dsql_exec_immed2 () from /usr/lib/libgds.so
#13 0x41b10de3 in isc_dsql_execute_immediate () from /usr/lib/libgds.so
#14 0x0806e023 in FirebirdDriver::create(CompanyDefn&) (this=0x80bacf4,
company=@0xbfffe1c0) at firebird_driver.cpp:179
--
Brad Pepers
brad@...
and loading the libgds.so library at runtime with dlopen. The application is
also compiled with Qt setup to use threads so it links with qt-mt.so and all
this is on Redhat 9. What is happening is that a segfault happens when I try
to create a company using isc_dsql_execute_immediate. The backtrace I get
shows me the segfault is happening in the ParsedPath::~ParsedPath when it
calls operator delete[]. The operator delete[] it uses comes from the
qt-mt.so library because it redefines it for thread safety concerns I
imagine.
So the question is whether the problem is with Qt redefining operator delete[]
in some bad way or is it with Firebird. Looking at the dir_list.cpp code it
looks like the memory for PathElem is allocated using FB_NEW and some memory
pool mechanism. If so, is it really safe to deallocate that memory using
operator delete[] or shouldn't there be a FB_DELETE? Or is the problem that
the alloc.h inlines operator new[] so that version gets used there but
operator delete[] is not inline so it has to be linked and if there is a
different operator delete[] in one of the other libraries.
Anyway its a problem for anyone who wants to link Firebird in at runtime when
the are using a library that defines its own operator delete[]. Actually the
same problem happens if I give "-lqt-mt -lgds" to the linker though it
doesn't if I instead use "-lgds -lqt-mt". I sure hope there is a way to fix
this since otherwise there is no runtime loading of Firebird!
Here is the backtrace:
#0 0x42074760 in _int_free () from /lib/tls/libc.so.6
#1 0x42073786 in free () from /lib/tls/libc.so.6
#2 0x405c37a3 in operator delete(void*) ()
from /usr/lib/qt-3.1/lib/libqt-mt.so.3
#3 0x405c37cf in operator delete[](void*) ()
from /usr/lib/qt-3.1/lib/libqt-mt.so.3
#4 0x41c3c649 in ParsedPath::~ParsedPath() () from /usr/lib/libgds.so
#5 0x41c40258 in DirectoryList::IsPathInList(Firebird::PathName const&) ()
from /usr/lib/libgds.so
#6 0x41b859fe in ISC_lookup_entrypoint () from /usr/lib/libgds.so
#7 0x41b85681 in ISC_lookup_entrypoint () from /usr/lib/libgds.so
#8 0x41b16d2e in isc_unwind_request () from /usr/lib/libgds.so
#9 0x41b0d407 in isc_attach_database () from /usr/lib/libgds.so
#10 0x41bdd261 in PREPARSE_execute () from /usr/lib/libgds.so
#11 0x41b11303 in isc_dsql_exec_immed2_m () from /usr/lib/libgds.so
#12 0x41b11025 in isc_dsql_exec_immed2 () from /usr/lib/libgds.so
#13 0x41b10de3 in isc_dsql_execute_immediate () from /usr/lib/libgds.so
#14 0x0806e023 in FirebirdDriver::create(CompanyDefn&) (this=0x80bacf4,
company=@0xbfffe1c0) at firebird_driver.cpp:179
--
Brad Pepers
brad@...