Re: [Boost-users] [filesystem] std::bad_alloc during dll initialization when migrating to filesystem v3
I can not reproduce the behavior with a toy project containing 3 dlls that all use boost::filesystem. It might be some incompatibility with another library. But with filesystem v2 it works. So, what should I look for. I searched google extensively for std::bad_alloc during dll initialization, but found no solution so far. Rgds Richard
Date: Wed, 13 Apr 2011 16:51:41 +0200 From: Richard Ulrich <richi@paraeasy.ch> To: boost-users@lists.boost.org Subject: [Boost-users] [filesystem] std::bad_alloc during dll initialization when migrating to filesystem v3 Message-ID: <1302706301.2665.13.camel@one> Content-Type: text/plain; charset="us-ascii"
Hi Guys,
I'm currently migrating our system consisting of multiple dll's and and executable to filesystem v3. The first two dll's that use boost::filesystem load ok, but the third fails with std::bad_alloc in the locale copy constructor called from default_locale during the construction of dot_path.
I don't know if it's relevant, but we usually work with char while filesystem uses wchar_t for BOOST_WINDOWS_API
Rgds Richard
On Apr 15, 2011, at 7:53 AM, Richard Ulrich <richi@paraeasy.ch> wrote:
I can not reproduce the behavior with a toy project containing 3 dlls that all use boost::filesystem.
Wild guess: are you linking static boost::filesystem with each of your DLLs, or dynamic boost::filesystem? Bad Things can happen with multiple static instances of the same library in the same process.
Wild guess: are you linking static boost::filesystem with each of your DLLs, or dynamic boost::filesystem? Bad Things can happen with multiple static instances of the same library in the same process.
If I link the filesystem lib as dll, then it works. Thanks for the hint. Should I file a bug, or is there a trick to suppress multiple initialization? We have used static versions of the boost libs in different dll's for years, and never ran into similar problems. Rgds Richard
On Mon, Apr 18, 2011 at 10:53 AM, Richard Ulrich <richi@paraeasy.ch> wrote:
If I link the filesystem lib as dll, then it works. Should I file a bug, or is there a trick to suppress multiple initialization?
We have used static versions of the boost libs in different dll's for years, and never ran into similar problems.
This isn't a boost thing -- it's a DLL thing. Any static library bound into multiple DLLs in the same process could cause you problems. More specifically, every static variable in that static library will have a distinct instance per DLL. Generally, coders use static variables to share state among all callers. That is, we assume a single instance of any particular static variable. You can see that it becomes problematic when that assumption is violated -- though the nature of the symptoms strongly depends on the use of that variable, the specific pattern of calls between DLLs, etc. If the library of interest happens to have no static variables -- or if, in your usage, you don't happen to cause it to modify any of its static variables -- you can get away with multiple instances in the process. That's a tough thing to guarantee for a third-party library, though, and -- as you've seen -- it can change from release to release. My rule of thumb is to prefer dynamic libraries, with two exceptions: 1. If I'm building my entire application as a single executable, it's okay to link it with static libraries. 2. If I can guarantee that, in my executable and all its dynamic libraries, only *one* of them uses a particular library, it's okay to link that library statically into the dynamic library in question. (But that too is subject to change over time, particularly with the kinds of general-purpose libraries provided by Boost.) This isn't a Boost bug.
participants (3)
-
Nat Goodspeed -
Nat Linden
-
Richard Ulrich