Archived

This forum has been archived. Please start a new discussion on GitHub.

Can't use same Slice definition in shared library and executable

benh
benh
in Bug Reports
Hi,

I am experiencing a coredump in our application which is made up of a shared library and an executable which both use the same Slice interface. More specifically they share a .ice file which defines some common types.

This problem occurs in a much larger application where (for reasons I won't go into here) it makes sense to use Ice in both places. However I have put together a small testcase to illustrate the problem.

Interestingly, if the "Foo" class is turned into a struct the problem does not occur. Also if "Bar" is turned into a method instead of a data member the problem also does not occur.

Problem can be reproduced in both Ice 3.3.0 and 3.3.1 and has been confirmed on both Fedora 8 64-bit Linux and Mac OSX.

Say I have a Slice definition file:
// Filename: CommonTypes.ice
#ifndef COMMONTYPES_ICE
#define COMMONTYPES_ICE

module interfaces
{
    class Foo { 
        bool bar;
    };
    
};
#endif


and a library which includes the resulting header file:
// Filename: mylib.cpp
#include <Ice/Ice.h>
#include "CommonTypes.h"

// Really don't need anything here

Now we compile like so: 
slice2cpp CommonTypes.ice
g++ -Wall -g -fPIC -I$(ICE_HOME)/include -I. -c CommonTypes.cpp
g++ -Wall -g -fPIC -I$(ICE_HOME)/include -I. -c mylib.cpp
g++ -shared -L$(ICE_HOME)/lib -L. -o libmylib.so mylib.o CommonTypes.o -lIce


Now we create an executable:
// Filename: executable.cpp
#include <Ice/Ice.h>
#include "CommonTypes.h"

int main(int argc, char *argv[])
{
    return 0;
}

Compile like so, linking with the shared library we created earlier:
g++ -Wall -g -fPIC -I$(ICE_HOME)/include -I. -c executable.cpp
g++ -L$(ICE_HOME)/lib -L. -o executable executable.o CommonTypes.o -lmylib -lIce

Now running this executable results in a coredump:
$ LD_LIBRARY_PATH=$LD_LIBRARY_PATH:. ./executable
Segmentation fault (core dumped)

$ gdb executable core.32671
GNU gdb Red Hat Linux (6.6-45.fc8rh)

<<< Cut some less interesting stuff >>>

(gdb) where
#0 0x0000003317c9c968 in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string () from /usr/lib64/libstdc++.so.6
#1 0x000000000083c61a in pair (this=0x7ffffc077ea0, __a=@0x614708, __b=@0x7ffffc077ec0) at /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/stl_pair.h:85
#2 0x000000000083d1e3 in std::map<std::string, std::pair<IceInternal::Handle<Ice::ObjectFactory>, int>, std::less<std::string>, std::allocator<std::pair<std::string const, std::pair<IceInternal::Handle<Ice::ObjectFactory>, int> > > >::operator[] (this=0xe194e8, __k=@0x614708)
at /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/stl_map.h:348
#3 0x000000000083aa96 in IceInternal::FactoryTableDef::addObjectFactory (this=0xe19490, t=@0x614708, f=@0x614710) at FactoryTableDef.cpp:109
#4 0x000000000040dc87 in __F__interfaces__Foo__Init (this=0x327b58) at CommonTypes.cpp:196
#5 0x000000000011e772 in __static_initialization_and_destruction_0 (__initialize_p=1, __priority=65535) at CommonTypes.cpp:205
#6 0x000000000011e7c5 in global constructors keyed to _ZN11IceInternal6upCastEPN10interfaces3FooE () at CommonTypes.cpp:234
#7 0x0000000000122c36 in __do_global_ctors_aux () from /work/hum092/ice_bug/libmylib.so
#8 0x000000000011ce5b in _init () from /work/hum092/ice_bug/libmylib.so
#9 0x00007ffffc078108 in ?? ()
#10 0x000000330440d67b in call_init () from /lib64/ld-linux-x86-64.so.2
#11 0x000000330440d785 in _dl_init_internal () from /lib64/ld-linux-x86-64.so.2
#12 0x0000003304400afa in _dl_start_user () from /lib64/ld-linux-x86-64.so.2
#13 0x0000000000000001 in ?? ()
#14 0x00007ffffc07a3cd in ?? ()
#15 0x0000000000000000 in ?? ()

Comments

  • benoit
    benoit Rennes, France
    Hi,

    I believe you won't get this crash if you compile your exe without including CommonTypes.o (it's included in the shared library mylib already):
    g++ -L$(ICE_HOME)/lib -L. -o executable executable.o -lmylib -lIce

    You only get the crash for Slice classes without methods because only these classes are registered with the object factory global map. In any case, it's not clear to me why this crash occurs... we'll have a closer look at this.

    Cheers,
    Benoit.
  • benh
    benh
    benoit wrote: »
    I believe you won't get this crash if you compile your exe without including CommonTypes.o

    Hi Benoit,

    Thanks for your reply. Unfortunatly the object file needs to be included in both, because both exe and library can be used separatly. The library is actually a log4cxx appender plugin and logs to an IceStorm topic. It can be used with any app which uses log4cxx. The exe can also be used without this particular log appender, say if one just wanted to log to stdout.

    Regards,
    Ben
  • benoit
    benoit Rennes, France
    Hi,

    In this case, I would create a shared library that contains all the shared objects and link the plugin and the exe with this library.

    Cheers,
    Benoit.

Categories