Re: [firebird-devel] Firebird 1.5 segfault

[Brad P. <br...@li...>]

> 1. valgrind is not supposed to work with Firebird 1.5. It doesn't
> understand hierarchical pools sub-allocation (this may be worked
> around, but in tool-dependent way, this will partly be solved in
> Firebird 2.0).

Alright.  I think you can give valgrind a list of things it thinks are error 
but for it to ignore them so perhaps we could create one for Firebird so 
valgrind could still be used with programs linked with Firebird and not have 
tons of errors showing up.

> 2. there is no substantial difference between server engine and client
> library. For example, when you link to libfbembed.so you actually link
> to full-fledged embeeded server engine.

So to get this straight, should there be a fbclient library and is that what 
the client programs should link with or can I link with fbembed and use that 
in a client?  If I'm supposed to be using fbclient then its missing from the 
RPM package I got.

> The strategic mistake was usage of STL objects in Firebird memory
> pools (this forces us to re-define global delete). The fix is in
> progress in FB2.0 tree (all needed classes are implemented and are
> just pending to replace STL analogs).

I've had problems with the STL library before as well and using it can cause 
more problems than it solves!  Its a great idea but I've never found a STL 
library that didn't cause me other problems.

> I'll take a look at FB1.5 codebase and will recon what can be done
> there with this problem. And yes, this is the real problem.

Thanks!  Its a real show stopper at least for me and I assume it will bite 
other people when they link with libstdc++ in the wrong order or try to 
dynamically load the library.

-- 
Brad Pepers
br...@li...