Menu
▾
▴
firebird-devel
|
From: Fred P. Jr. <fp...@us...> - 2003-10-28 11:43:18
|
--- Brad Pepers <br...@li...> wrote: > All in all it makes my application that much more difficult to > install and get running because of Firebird not playing nice. Thanks Brad. I hereby retract my "release notes solution" idea. While LD_PRELOAD works, I see that it could be a pain for you in a multi-dbms environment. > I hope that a solution can be found for the 1.5 release... I agree, it would be better to resolve this problem in FB 1.5 so that C++ developers don't have to worry about global delete operator conflicts. Regards, --Fred P. |
|
From: Brad P. <br...@li...> - 2003-10-26 19:29:23
|
> I installed FirebirdCS-1.5.0.3780-RC6.i686.rpm on a system running > RH8+updates and was able to reproduce your segfault. I did, however, get a > different stack trace (below). This may be because I recently installed gdb > 6.0 on this system to get some debugger fixes. In my case, the segfault is > coming from the -lstdc++ library delete operator, which makes more sense: Yes that does make more sense. Especially since qt-mt doesn't even define operator delete[]! I figured gdb must be getting something wrong in the back trace. > So, whichever library gets linked into your application first defines the > delete operators -- the order of libraries given to the linker is > important. So, as you already know, link with -lgds as the first library in > your link command and you shouldn't see segfaults. The problem I have is that what I'm really going is loading libgds.so dynamically at runtime using dlopen which means I have no control over whats already linked in. So it looks like if my program links with stdc++ then I can't dynamically load libgds.so but I think most C++ programs will do this so it won't ever work. Also it sounds like the client library isn't even supposed to be using the memory pool and also the valgrind output shows that things aren't right even when I do link things in the right order. I think things are rotten in here and need to be fixed! PS: I replied to this originally without realizing it was on the firebird-support list that you responded. We should keep this thread to one list and it was suggested to me that the devel list would be best so I'll watch and only post to devel now. -- Brad Pepers br...@li... |
|
From: Nickolay S. <sk...@bs...> - 2003-10-26 20:07:47
|
Hello, Brad, > Also it sounds like the client library isn't even supposed to be using the > memory pool and also the valgrind output shows that things aren't right even > when I do link things in the right order. I think things are rotten in here > and need to be fixed! 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). 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. 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'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. > Brad Pepers -- Nickolay Samofatov mailto:sk...@bs... |
|
From: Brad P. <br...@li...> - 2003-10-26 20:51:49
|
> 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... |
|
From: Fred P. Jr. <fp...@us...> - 2003-10-27 05:57:17
|
Brad Pepers wrote:
> 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.
>
Hi Brad,
Good news -- there is a workaround. You're lucky because you're running on a platform that uses an ld.so style dynamic linker! Until this is resolved, try using something like the following command to execute your FB applications:
env LD_PRELOAD=/usr/local/firebird/lib/libfbembed.so fb_test
The LD_PRELOAD variable tells the dynamic linker to preload the specified library/libraries before any others. The "env" command above will set the environment variable as specified and then run your application which will inherit the new setting. For you this means your app. should run correctly regardless of the library order used to link it.
However, do not set LD_PRELOAD to this value in the environment of any non-FB C++ programs. For example, don't set this in your .cshrc, .profile or .bashrc files. Forcing other programs to use the FB delete operators, when they expect to use the -lstdc++ delete operators, could result in... unpleasant happenings. ;-)
You should be okay if you use the "env" program as shown above AND your application doesn't spawn any child processes that run non-FB C++ programs.
Hope this helps,
---Fred P.
P.S. Here's an excerpt from the RH8 man page for ld.so, if you need a little more info on this env. variable:
LD_PRELOAD
A whitespace-separated list of additional, user-specified, ELF
shared libraries to be loaded before all others. This can be
used to selectively override functions in other shared
libraries. For setuid/setgid ELF binaries, only libraries in
the standard search directories that are also setuid will be
loaded.
|
|
From: Milan B. <al...@eu...> - 2003-10-29 12:04:16
|
Fred Polizo Jr. wrote: > Good news -- there is a workaround. You're lucky because you're running > on a platform that uses an ld.so style dynamic linker! Until this is > resolved, try using something like the following command to execute your > FB applications: > env LD_PRELOAD=/usr/local/firebird/lib/libfbembed.so fb_test > > The LD_PRELOAD variable tells the dynamic linker to preload the > specified library/libraries before any others. The "env" command above > will set the environment variable as specified and then run your > application which will inherit the new setting. For you this means your > app. should run correctly regardless of the library order used to link it. I tried to use LD_PRELOAD with my app that uses IBPP library, and my problem is gone as well. At least it seems that way. -- Milan Babuskov http://fbexport.sourceforge.net |
|
From: Nickolay S. <sk...@bs...> - 2003-10-27 21:41:32
|
Hello, Brad ! >> 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. You are may use libfbembed.so as a client library (or as embeeded local server) for single-threaded applications. You should use libfbclient.so for multi-threaded applications. I can include libfbclient.so in CS RPM if there are no objections. >> 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. 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). We need to make sure that our header is always included before system <new> and prevents it from inclusion (via defining __NEW__ actually). We also need to include the header with re-defined operators for each module that uses them (thus I added it to firebird.h). This approach will fail if something from the following changes: 1. static inline functions are always expanded and are not exported 2. none of STL code that Firebird uses is contained in libstdc++5.so, in particular no pre-instantiated templates are used 3. STL templates are not pre-compiled I hope this is a temporary solution. I think to commit it to CVS HEAD tomorrow and let people test it. If there are no problems, I'll backport it to B1_5_Release branch. Suggestions ? -- Nickolay Samofatov mailto:sk...@bs... |
|
From: Milan B. <al...@eu...> - 2003-10-28 14:54:15
|
Nickolay Samofatov wrote: > You are may use libfbembed.so as a client library (or as embeeded > local server) for single-threaded applications. You should use > libfbclient.so for multi-threaded applications. > > I can include libfbclient.so in CS RPM if there are no objections. Please do. I'm wondering: Does this mean that I can take libfbclient.so from FirebirdSS package and link it against my app, even if my app is not multi-threaded? -- Milan Babuskov http://fbexport.sourceforge.net |
|
From: Nickolay S. <sk...@bs...> - 2003-10-28 15:31:25
|
Hello, Milan ! > Nickolay Samofatov wrote: >> You are may use libfbembed.so as a client library (or as embeeded >> local server) for single-threaded applications. You should use >> libfbclient.so for multi-threaded applications. >> >> I can include libfbclient.so in CS RPM if there are no objections. > Please do. I'm working on this. > I'm wondering: Does this mean that I can take libfbclient.so from > FirebirdSS package and link it against my app, even if my app is not > multi-threaded? Yes. But not that libfbclient.so cannot be used for local direct access to database, only TCP/IP connections are supported with this library. -- Nickolay Samofatov mailto:sk...@bs... |
|
From: Fred P. Jr. <fp...@us...> - 2003-10-28 05:44:26
|
--- 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. |
|
From: Helen B. <he...@tp...> - 2003-10-28 07:16:04
|
At 09:43 PM 27/10/2003 -0800, Fred Polizo Jr. wrote: >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. Fred and whoever, This problem is far too esoteric for me to keep a handle on. If/when the "solution" is to document it in the release notes, please FIRST write an an authoritative, signed readme and upload it to /doc, letting me know it is there. My preference would be to add a note in the "Compatibility" section with a very broad description of the problem (which you would need to supply, as I'm not a C++ programmer) and direct the reader to /doc. The readme should probably be distributed in the source tarball, too. Then at least you can keep the readme up to date and not rely on the release notes to be up-to-date enough for people who're rolling their own binaries from latest sources. Helen |
|
From: Brad P. <br...@li...> - 2003-10-28 07:56:49
|
On October 27, 2003 10:43 pm, Fred Polizo Jr. wrote: > --- 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 LD_PRELOAD is also messy with my situation at least and I imagine for others that want to load the library at runtime. The main reason for doing this is if you support more than one database type in your application so now I have to handle that when my application is first installed, Firebird may not be used but down the road it may be added so when the Firebird support is loaded, it will have to move things around and then also undo it when its removed. All in all it makes my application that much more difficult to install and get running because of Firebird not playing nice. I hope that a solution can be found for the 1.5 release that fixes things! > 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? Yes I'm not sure what else will be effected which is an argument to find a fix for Firebird rather than work arounds for each case. > 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. Yes I can work around it and then each other application that has the same problem can all work around it but it will remain an odd gotchya and will cause fixes in other applications to work around a problem in Firebird. > 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. Early on there were postings that the client code shouldn't even be using the memory pool code. Is this the case? Is it a matter of the memory pool code being used in too many places where it shouldn't be? As long as I don't actually create a database, I can connect to one and run SQL commands against it and everything. It just seems to hit me when I create a database. Though it was reported that the same error happens when a wrong username/password is used to connect to a database. > 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. Of course being the one effected by it I would hope for an actual fix but I realize the constraints of getting a Firebird 1.5 release out there. It was also posted by Milan Babuskov that he gets a very similar problem under other circumstances and I think trying to ignore a problem like this rather than fix it will cause more grief in the long run. -- Brad Pepers br...@li... |
|
From: Fred P <fps...@ya...> - 2003-10-28 10:44:01
|
--- Brad Pepers <br...@li...> wrote: > All in all it makes my application that much more difficult to > install and get running because of Firebird not playing nice. Thanks Brad. I hereby retract my "release notes solution" idea. While LD_PRELOAD works, I see that it could be a pain for you in a multi-dbms environment. > I hope that a solution can be found for the 1.5 release... I agree, it would be better to resolve this problem in FB 1.5 so that C++ developers don't have to worry about global delete operator conflicts. Regards, --Fred P. __________________________________ Do you Yahoo!? Exclusive Video Premiere - Britney Spears http://launch.yahoo.com/promos/britneyspears/ |
|
From: Fred P. Jr. <fp...@us...> - 2003-10-28 13:23:16
|
--- Nickolay Samofatov <sk...@bs...> wrote:
>>> Aren't FB 's global delete operators defined for all
>>> platforms, not just GNU/linux?
...
>> Can somebody please confirm or disprove Fred's core sentence above?
> 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.
Hi Nickolay,
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?
If you agree this would be a problem, then does your patch resolve this case as well as the GNU STL case?
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?
void operator delete(void* mem) throw() {
Firebird::MemoryPool::globalFree(mem);
}
void operator delete[](void* mem) throw() {
Firebird::MemoryPool::globalFree(mem);
}
Thanks,
---Fred P.
|
|
From: Nickolay S. <sk...@bs...> - 2003-10-28 13:53:45
|
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...
|
|
From: Fred P. Jr. <fp...@us...> - 2003-10-30 13:08:24
|
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. |
|
From: Mike N. <ta...@al...> - 2003-10-30 17:57:14
|
Fred Polizo Jr. wrote: > So, you're saying MSVC allows multiple/different global delete operators > in one program? Only to the extent the language allows/mandates. The problem is introduced by linking with libraries that also define global operator delete function(s). That means an overloaded operator new function within "the code" [1] could be used within the context of "the code" code, but if such a library was linked before this module, "the code" would pick up the library's operator delete function. Obvious heap function mismatch and - boom. [1] "the code" is here defined to be "your" (e.g. fb client library) code, as opposed to the library linked with. /Mike |
|
From: Nickolay S. <sk...@bs...> - 2003-10-30 13:55:43
|
Hello, Fred ! > 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. 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. > 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. Mail it to me, please. > 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). ... Microsoft violates this rule in DLL's. And I think that was one of a few wise Microsoft decisions. > 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. I'll probably make a look at MSVC build before backporting my changes to FB1.5. > Regards, > ---Fred P. -- Nickolay Samofatov mailto:sk...@bs... |
|
From: Fred P. Jr. <fp...@us...> - 2003-10-31 10:15:48
|
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. Rather than post the verbose backtraces, I'm e-mailing you the source for the modified test program, as you requested, so you can resolve any questions you may have. > Microsoft violates this [ODR] rule in DLL's. And I think that was one of a > few wise Microsoft decisions. If you don't mind confusing, proprietary, non-portable code. We'll just have to "agree to disagree" on this point. ;-) >> If someone with a MSVC compiler wants to try the test program ... > I'll probably make a look at MSVC build before backporting my changes > to FB1.5. Sounds good! Regards, ---Fred P. |
|
From: Olivier M. <om...@ti...> - 2003-10-31 10:50:25
|
Dear, On Fri, 31 Oct 2003 02:15:46 -0800, Fred Polizo Jr. wrote : > > Microsoft violates this [ODR] rule in DLL's. And I think that was one of a > > few wise Microsoft decisions. > > If you don't mind confusing, proprietary, non-portable code. We'll just have to "agree to disagree" on this point. ;-) > > >> If someone with a MSVC compiler wants to try the test program ... > > I'll probably make a look at MSVC build before backporting my changes > > to FB1.5. > > Sounds good! The comment that Mike Nordell posted on this matter on Thu, 30 Oct 2003 18:14:44 +0100, sounds even better and is worth a review. My 2 -cents, -- Best Regards, Olivier Mascia |
|
From: Olivier M. <om...@ti...> - 2003-10-31 10:57:44
|
Dear, On Fri, 31 Oct 2003 11:50:14 +0100, Olivier Mascia wrote : > The comment that Mike Nordell posted on this matter on Thu, 30 Oct > 2003 18:14:44 +0100, sounds even better and is worth a review. Mistake : that was actually on Thu, 30 Oct 2003 18:02:59 +0100 in another thread of the discussion. Nicholay Samofatov already commented. What if all dynamically objects derived from a common base ? -- Best Regards, Olivier Mascia |
|
From: Nickolay S. <sk...@bs...> - 2003-10-31 18:15:59
|
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... |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X