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

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

Hello, Fred !

>> It is ~60% wrong. My solution fully resolves the problem when Firebird
>> is compiled with GNU STL. The problem doesn't and didn't exist for
>> MSVC environment.

> What happens if a user application defines its own global delete
> operators and then links in the FB client library? Are you saying
> there would be no problem?

After my patches there should be no problem. Test it, please.

> I agree the GNU STL problem wouldn't exist for MSVC, but isn't there
> still a problem where a Win32 FB app. defines its own delete
> operators. Perhaps I'm missing something about the Win32 build, but
> I just checked src/common/classes/alloc.cpp and I see two global
> delete operators defined near the end of the file (below). I don't
> see any "#ifndef WIN_NT/#endif" around these two definitions, so why
> would they not be defined in the Win32 client library? Is alloc.cpp
> not part of the Win32 client library?

It is used in Win32 client libary too. But Win32 has different
approach to dynamic linking. Win32 entrypoint is identified by module
and name, not only name as on Linux ELF SO.

> void operator delete(void* mem) throw() {
>         Firebird::MemoryPool::globalFree(mem);
> }

> void operator delete[](void* mem) throw() {
>         Firebird::MemoryPool::globalFree(mem);
> }

^^^^^^^^^^^
In addition, this entrypoints cannot affect other modules in normal
MSVC build because they are not declared as __declspec(dllexport).



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