Re[2]: [firebird-devel] Firebird 1.5 segfault

[Nickolay S. <sk...@bs...>]

Hello, Fred !

> Nickolay Samofatov wrote:
>> Could you publish backtraces of this calls ? They should originate
>> from initialization of STL library. If this is not the case this may
>> cause serious problems.

> I looked at the new and delete runtime calls when I first noticed
> them. They originate from STL usage in the FB database creation
> code, in the FB library. IMO, this is correct. An STL implementation
> that makes calls to "the" global new or delete operators *should*
> call the replacement operators defined in the program object file.
> That's what is happening. Since your hack relates to certain FB
> defined classes, not STL classes, I don't think there is a problem
> with these calls.

My hack intended apply to all allocations, STL and non-STL too.
Bad news is that Firebird uses global allocator via pre-instantiated
STL classes. std::string is used in a number of places. File input streams
are used in the other (configuration manager).

Only hope is that this objects are not partly-instantiated and
allocation is not mixed in instantiated and non-instantiated parts for
this classes. Otherwise we are going to have memory corruption
problems.

2Alex: could you take a look at this issues when you finish
implementation of Firebird string class ?

> ---Fred P.


-- 
Nickolay Samofatov                        mailto:sk...@bs...