Brad Pepers wrote:

> So the question is whether the problem is with Qt redefining operator delete[]
> in some bad way or is it with Firebird.

I just had a few minutes free to test this. So, this isn't an in-depth analysis, but I think I have another explanation for you segfault...

I installed FirebirdCS-1.5.0.3780-RC6.i686.rpm on a system running RH8+updates and was able to reproduce your segfault. I did, however, get a different stack trace (below). This may be because I recently installed gdb 6.0 on this system to get some debugger fixes. In my case, the segfault is coming from the -lstdc++ library delete operator, which makes more sense:

#0 0x4098ff54 in free () from /lib/libc.so.6
#1 0x40561853 in operator delete(void*) (ptr=0x8000000)
at ../../../../libstdc++-v3/libsupc++/del_op.cc:39
#2 0x4056187f in operator delete[](void*) (ptr=0x8000000)
at ../../../../libstdc++-v3/libsupc++/del_opv.cc:36
#3 0x407ce649 in ParsedPath::~ParsedPath() () from /usr/lib/libfbembed.so.1
#4 0x407d2258 in DirectoryList::IsPathInList(Firebird::PathName const&) ()
from /usr/lib/libfbembed.so.1
#5 0x407179fe in ISC_lookup_entrypoint () from /usr/lib/libfbembed.so.1
#6 0x40717681 in ISC_lookup_entrypoint () from /usr/lib/libfbembed.so.1
#7 0x406a8d2e in isc_unwind_request () from /usr/lib/libfbembed.so.1
#8 0x4069f407 in isc_attach_database () from /usr/lib/libfbembed.so.1
#9 0x4076f261 in PREPARSE_execute () from /usr/lib/libfbembed.so.1
#10 0x406a3303 in isc_dsql_exec_immed2_m () from /usr/lib/libfbembed.so.1
#11 0x406a3025 in isc_dsql_exec_immed2 () from /usr/lib/libfbembed.so.1
#12 0x406a2de3 in isc_dsql_execute_immediate () from /usr/lib/libfbembed.so.1
#13 0x0804867c in main (argc=2, argv=0xbffff484) at fb_test.cpp:15

The real "conflict" appears to be with the -lstdc++ library which also defines global delete and delete[] operators (see "P.S." below for details). I replaced -lqt-mt with -lstdc++ in your link command and it produces a runtime segfault as well:
g++ -g -O0 -o fb_test fb_test.o -lstdc++ -lgds

So, whichever library gets linked into your application first defines the delete operators -- the order of libraries given to the linker is important. So, as you already know, link with -lgds as the first library in your link command and you shouldn't see segfaults.

I Gotta run... hope this helps,
---Fred P.

P.S. I used 'nm' to dump the external symbols from the the two libraries. Here you can see that each library defines global delete operators:

$ nm -g -C -D /usr/lib/gcc-lib/i386-redhat-linux/3.2/libstdc++.so | grep 'operator delete'
00089e20 T operator delete[](void*)
00089e50 T operator delete[](void*, std::nothrow_t const&)
00089dc0 T operator delete(void*)
00089df0 T operator delete(void*, std::nothrow_t const&)

$ nm -g -C -D /usr/lib/libgds.so | grep 'operator delete'
0016d4d0 T operator delete[](void*)
0016d480 T operator delete(void*)
00099570 W pool_alloc<(short)4>::operator delete(void*)
0011df60 W pool_alloc_rpt<char, (short)17>::operator delete(void*)
000845e0 W pool_alloc_rpt<char, (short)22>::operator delete(void*)
0011dfa0 W pool_alloc_rpt<char, (short)6>::operator delete(void*)