Boost C++ Libraries: Ticket #8414: flyweights causes weird library initialization error

attachment set

Sun, 07 Apr 2013 15:37:45 GMT

attachment → test_case

status changed; resolution set

Joaquín M López Muñoz — Sun, 07 Apr 2013 18:09:00 GMT

status new → closed
resolution → invalid

Hi Charles,

I've been examing the scenario and these are my conclusions (which lead me to think this is not a bug in Boost.Flyweight, hence I'm closing the ticket, please feel free to reopen if in disagreement):

You're checking the succesfull closing of the dynamic library incorrectly:

    if (dlclose(foo) < 0) {
        ...
    }

when it should be

    if (dlclose(foo) != 0) {
        ...
    }

My thesis is then that dlclose is then failing to close the dynamic lib because, according to the Linux documentation on the command, some other module is sharing some symbol with it. I think the shared symbol is getEmptyStringSymbol and the sharing module is 'libpluginTest.so' again, which, additionally to its being loaded dynamically, it's also linked at build time:

g++ -I/path/to/boost/includes -fPIC -shared -rdynamic test_plugin.cpp -o libpluginTest.so -L/path/to/boost/libs -lrt

My take is that if you omit -o libpluginTest.so everything will behave as you expect.

Best regards,

Mon, 08 Apr 2013 14:14:02 GMT

Hi joaquin,

i don't understand what makes you believe the plugin is being link at build time; main.cpp is the executable doing the module, and it is being built with the simple command: g++ main.cpp -o xmain -ldl as you see, nothing besides the libdl for dlopen and dlclose are being linked.

the command line 'g++ -I/path/to/boost/includes -fPIC -shared -rdynamic test_plugin.cpp -o libpluginTest.so -L/path/to/boost/libs -lrt' it is the one building and linking the plugin. Since it is a single translation unit, the linking can be done at once. The -o libxxxx.so is not required but it is a cosmetic choice to avoid having to link a library called a.out

i hope this helps

Joaquín M López Muñoz — Mon, 08 Apr 2013 15:19:00 GMT

Yep, my fault, I skimmed through the test case and thought the referred to commandline was the one used for building the main executable.

OK, so we have dlclose failing for no apparent reason (can you confirm dlclose indeed returns something !=0?) Boost.Flyweight creates static objects for the value factory using this so-called holder:

template<typename C>
struct static_holder_class:holder_marker
{
  static C& get()
  {
    static C c;
    return c;
  }
};

which looks suspiciously similar to the problem described at

http://stackoverflow.com/questions/11050693/dlclose-doesnt-work-with-factory-function-complex-static-in-function

Could you try using --no-gnu-unique as desribed in the post above?

Mon, 08 Apr 2013 15:59:45 GMT

that option is only available at build's time of the compiler, is not a run-time option. However that problem description looks pretty similar to what we are seeing here.

So you are saying that this is a compiler bug/mis-feature?

Mon, 08 Apr 2013 16:48:16 GMT

I installed the gold plugin and build the plugin with this:

g++ -I/path/to/boost/includes -fPIC -shared -rdynamic -Wl,--no-gnu-unique test_plugin.cpp -o libpluginTest.so -L/path/to/boost/libs -lrt

$ ld --version GNU gold (GNU Binutils for Ubuntu 2.22.90.20120924) 1.11

running the program produces the expected result: the library is closed before dlclose returns:

load: Library constructor: address of static cbContainer is: load: library loaded 0x2237030 Library destructor: load: library closed

so this is indeed a bug or misfeature of ld. I have no idea why this is the default behavior.

Joaquín M López Muñoz — Mon, 08 Apr 2013 17:07:22 GMT

Seems like a bug to me, rather than default behavior. Unfortunately GCC is not my area of expertise. Let's do a final try: you can resort to a user-defined holder with a slightly different behavior wrt static construction:

template<typename C>
struct GCC_dyn_holder_class:boost::flyweights::holder_marker
{
  static C c;
  static C& get()
  {
    return c;
  }
};
template<typename C> C GCC_dyn_holder_class<C>::c;
struct GCC_dyn_holder:boost::flyweights::holder_marker
{
  template<typename C>
  struct apply
  {
    typedef GCC_dyn_holder_class<C> type;
  };
};
typedef boost::flyweight<std::string,GCC_dyn_holder> SymbolName_t;

Does this change anything?

Mon, 08 Apr 2013 17:45:35 GMT

your sample with GCC_dyn_holder, using gold linker *WITHOUT* the --no-gnu-unique option, make dlclose behave *as expected*. But it seems to me that this kind of static holder (variable instead of function local) is not shared across modules. What do you think this implies?

Joaquín M López Muñoz — Mon, 08 Apr 2013 18:05:20 GMT

OK, we're getting somewhere :-)

But it seems to me that this kind of static holder (variable instead of function local) is not shared across modules.

In reality, moving c from function-static to global-static has nothing to do with module sharing, but it breaks some promises the lib makes as for when the flyweight factory is initialized (technically, during the so-called dynamic initialization phase of the program startup sequence.) Anyway, if you're not declaring any flyweight-dependent static variable in your module, then you're safe.

Now, about module sharing. As far as I know this does not make a difference (furthermore, given the symbol sharing capabilities of GCC you probably don't need anything like intermodule_holder.) But you can find out by yourself: just independently create two SymbolName_ts in different modules with the same content and check whether they're equal (which happens if they both point internally to the same value, hence sharing factory.) It is important that the two objects be created independently (that is, not one copied from the other) for the test to be valid.

Good luck,