Mystic segfault when using dlopen with static function with staticvariables inside it.

Discussion in 'C++' started by Markku Linnoskivi, Jan 13, 2012.

  1. Environment: Linux + g++ (4.3.X)

    Let there be the following classes:

    //libfoo <<<
    struct Bar
    {
    Bar()
    : s()
    {}

    Bar(const std::string& s_)
    : s(s_)
    {}

    std::string s;
    };

    struct Foo
    {
    static Bar getBar()
    {
    static Bar b;
    static done = false;

    if (done)
    {
    return b;
    }
    std::stringstream s;
    s << __FILE__ ;
    }
    };

    //libfoo >>>>

    //libX <<<
    struct FooObj
    {
    //has instance of Foo and calls Foo:getBar()
    };

    extern "C"
    {
    FooObj* create()
    {
    return new FooObj;
    }
    }
    //libX >>>

    The context is a plugin system where the plugins use a common library
    (libfoo) and appfoo is the host for the plugins.

    There is a shared library, call it, libX that calls Foo::getBar() at
    some point. And is linked during compile time to libfoo.
    There is an application appfoo that opens libX via dlopen and
    instantiates an FooObj from that library (using extern "C" function
    create). appfoo destroys the instantiated object, closes libfoo with
    dlclose and then later on opens it again with dlopen and creates a new
    instance of FooObj.

    At this point appfoo segfaults with a weird stack trace, mayby
    pointing to std::stringstream.

    What happens? This has to have something to do with the way GCC
    creates/destroys the static variables or something like that.
    Markku Linnoskivi, Jan 13, 2012
    #1
    1. Advertising

  2. Re: Mystic segfault when using dlopen with static function withstatic variables inside it.

    On 13 tammi, 14:10, Markku Linnoskivi <>
    wrote:
    > Environment: Linux + g++ (4.3.X)
    >
    > Let there be the following classes:
    >
    > //libfoo <<<
    > struct Bar
    > {
    >     Bar()
    >         : s()
    >     {}
    >
    >     Bar(const std::string& s_)
    >         : s(s_)
    >     {}
    >
    >     std::string s;
    >
    > };
    >
    > struct Foo
    > {
    >     static Bar getBar()
    >     {
    >         static Bar b;
    >         static done = false;
    >
    >         if (done)
    >         {
    >             return b;
    >         }
    >         std::stringstream s;
    >         s << __FILE__ ;
    >    }
    >
    > };
    >
    > //libfoo >>>>
    >
    > //libX <<<
    > struct FooObj
    > {
    > //has instance of Foo and calls Foo:getBar()
    >
    > };
    >
    > extern "C"
    > {
    >     FooObj* create()
    >     {
    >         return new FooObj;
    >     }}
    >
    > //libX >>>
    >
    > The context is a plugin system where the plugins use a common library
    > (libfoo) and appfoo is the host for the plugins.
    >
    > There is a shared library, call it, libX that calls Foo::getBar() at
    > some point. And is linked during compile time to libfoo.
    > There is an application appfoo that opens libX via dlopen and
    > instantiates an FooObj from that library (using extern "C" function
    > create). appfoo destroys the instantiated object, closes libfoo with
    > dlclose and then later on opens it again with dlopen and creates a new
    > instance of FooObj.
    >
    > At this point appfoo segfaults with a weird stack trace, mayby
    > pointing to std::stringstream.
    >
    > What happens? This has to have something to do with the way GCC
    > creates/destroys the static variables or something like that.



    getBar() was supposed to look like this:

    static Bar getBar()
    {
    static Bar b;
    static done = false;
    if (done)
    {
    return b;
    }
    done = true;
    std::stringstream s;
    s << __FILE__ ;
    b = Bar(s.str());
    return b;
    }
    Markku Linnoskivi, Jan 13, 2012
    #2
    1. Advertising

  3. Markku Linnoskivi

    Peter Guest

    Re: Mystic segfault when using dlopen with static function withstatic variables inside it.

    On Jan 13, 4:46 am, Markku Linnoskivi <>
    wrote:
    > On 13 tammi, 14:10, Markku Linnoskivi <>
    > wrote:
    >
    >
    >
    > > Environment: Linux + g++ (4.3.X)

    >
    > > Let there be the following classes:

    >
    > > //libfoo <<<
    > > struct Bar
    > > {
    > >     Bar()
    > >         : s()
    > >     {}

    >
    > >     Bar(const std::string& s_)
    > >         : s(s_)
    > >     {}

    >
    > >     std::string s;

    >
    > > };

    >
    > > struct Foo
    > > {
    > >     static Bar getBar()
    > >     {
    > >         static Bar b;
    > >         static done = false;

    >
    > >         if (done)
    > >         {
    > >             return b;
    > >         }
    > >         std::stringstream s;
    > >         s << __FILE__ ;
    > >    }

    >
    > > };

    >
    > > //libfoo >>>>

    >
    > > //libX <<<
    > > struct FooObj
    > > {
    > > //has instance of Foo and calls Foo:getBar()

    >
    > > };

    >
    > > extern "C"
    > > {
    > >     FooObj* create()
    > >     {
    > >         return new FooObj;
    > >     }}

    >
    > > //libX >>>

    >
    > > The context is a plugin system where the plugins use a common library
    > > (libfoo) and appfoo is the host for the plugins.

    >
    > > There is a shared library, call it, libX that calls Foo::getBar() at
    > > some point. And is linked during compile time to libfoo.
    > > There is an application appfoo that opens libX via dlopen and
    > > instantiates an FooObj from that library (using extern "C" function
    > > create). appfoo destroys the instantiated object, closes libfoo with
    > > dlclose and then later on opens it again with dlopen and creates a new
    > > instance of FooObj.

    >
    > > At this point appfoo segfaults with a weird stack trace, mayby
    > > pointing to std::stringstream.

    >
    > > What happens? This has to have something to do with the way GCC
    > > creates/destroys the static variables or something like that.

    >
    > getBar() was supposed to look like this:
    >
    > static Bar getBar()
    >     {
    >         static Bar b;
    >         static done = false;
    >         if (done)
    >         {
    >             return b;
    >         }
    >         done = true;
    >         std::stringstream s;
    >         s << __FILE__ ;
    >         b = Bar(s.str());
    >         return b;
    >    }



    you need to use the following flags for dlopen:

    RTLD_NOW | RTLD_LOCAL
    | RTLD_DEEPBIND

    see also

    http://groups.google.com/group/comp...024eba76b4?lnk=gst&q=dlclose#b65571024eba76b4
    Peter, Jan 17, 2012
    #3
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Steve Gilbert
    Replies:
    3
    Views:
    2,249
    Gordon Beaton
    Apr 14, 2004
  2. Thomas Matthews

    Re: dlopen() & undefined symbol

    Thomas Matthews, Jun 20, 2004, in forum: C++
    Replies:
    1
    Views:
    3,207
    John Harrison
    Jun 20, 2004
  3. Gernot Frisch

    OT: dlopen source

    Gernot Frisch, Sep 23, 2004, in forum: C++
    Replies:
    3
    Views:
    572
    Gernot Frisch
    Sep 23, 2004
  4. Andrey Vul
    Replies:
    8
    Views:
    683
    Richard Bos
    Jul 30, 2010
  5. Sur
    Replies:
    4
    Views:
    185
Loading...

Share This Page