Re: [firebird-devel] Firebird 1.5 segfault

[Fred P. Jr. <fp...@us...>]

Nickolay Samofatov wrote:
>>What happens if a user application defines its own global delete
>>operators and then links in the FB client library?  ...
>
> After my patches there should be no problem. Test it, please.

Hi,

Sorry for the delayed response. I've been very busy lately.

I added my own simple global new and delete operators to Brad's fb_test.cpp program. I build CS from the HEAD tree (anon CVS) -- I verified that your "hack" was included in alloc.h and alloc.cpp. I linked in libfbembed.so.

Indeed, the program no longer segfaults. My global new and delete operators were called by the FB client library, but no segfaults: five calls to "new" and four calls to "delete". The test program successfully created the FB database. So, this one case seems to work.

If requested, I'll post the source for the modified test program, should someone want to test other builds to see if they segfault with or without the hack patch.

> Win32 entrypoint is identified by module and name, not only name as on Linux ELF SO.
...
> In addition, this entrypoints cannot affect other modules in normal
> MSVC build because they are not declared as __declspec(dllexport).

So, you're saying MSVC allows multiple/different global delete operators in  one program? Sigh... So much for MSVC conforming to the standard C++ "one definition rule" (ODR):
 >...
> Every program shall contain exactly one definition of every non-inline function or object that is used in that program; no diagnostic required. The definition can appear explicitly in the program, it can be found in the standard or a user-defined library, or (when appropriate) it is implicitly defined (see class.ctor, class.dtor and class.copy). ...

If someone with a MSVC compiler wants to try the test program to confirm there is no problem in that build, let me know and I'll send the source code--its small.

Regards,
---Fred P.