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

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

--- Nickolay Samofatov <sk...@bs...> wrote:
 > It looks like I was able to create solution for this problem. It is
 > really dirty hack, actually. The idea of solution is to replace
 > operators and objects defined in STL <new> header with static inline
 > ours (given some GNU STL internals knowledge).

Hi Nickolay,

You're right... this is dirty!  ;)  ;)

The main problem I see with this solution is that it deals with only one 
problem case: GNU STL.  However, I believe this problem could occur 
whenever the FB client library is linked into an application that also 
defines global delete operators, either in user code or in some other 
library linked into the app. Aren't  FB 's global delete operators 
defined for all platforms, not just GNU/linux?

Also, as I posted yesterday, there already exists a workaround for 
Brad's GNU STL case: the "env LD_PRELOAD=<path of FB client lib>  
<user_app_executable>" command.   The LD_PRELOAD variable is a well 
known workaround for these kind of link order  problems.  So, I'm not 
sure patching the code for the same case, alone, is worth it.  

A better solution would be to eliminate the need for FB's global delete 
operators. But I realize that may not be possible without a fair amount 
of work.  Still, it is a rather "anti-social" for a library to assume 
that it can replace these global operators.   It restricts what users 
can do in their applications.

Of course, another "solution" might be to just document the workaround 
and the restrictions  in the release notes and change nothing in the 
code itself.  Essentially:
1) If you see the GNU STL delete operator segfault problem, use the "env 
LD_PRELOAD=..." command as a workaround.
2) WARNING for all platforms: user app's and any libraries they link in 
are restricted from defining C++ global new/delete operators. 

The "release notes" solution might be acceptable if the number of users 
affected by this problem is small.

Regards,
---Fred P.