0

for a research topic, I am using a C++ program to translate a SQL query into a C++ program. After translation, the c++ query source-code is compiled into a shared library:

g++ -O0 -g3 -fPIC -std=c++0x GeneratedQuery.cpp ../type/Types.cpp -shared -o lib.so

Everything works fine and the library is compiled correctly. In a second program, I try to implement a read-eval-print-loop which takes a query from the user, translates and compiles it, loads the shared library with dlopen and dlsym, and finally executes it. Before I used Intel TBB in the query-code everything worked fine, but now I get a segmentation fault for the second query I enter (fist query works perfectly, but second query that is loaded in the loop fails).

Source (read-eval-print-loop): http://pastebin.com/pWkRN7Dx

Sample Query-Code: http://pastebin.com/A1pBZC3d

If I do not have a join in my query and thus a single parallel_for occurs in the query source-code, there is no problem. But if there are multiple parallel_fors, I get a segmentation fault for the second query I enter (compilation is successful and dlopen works, but dlsym fails).

Here is the gdb output

0x00007ffff7de394b in ?? () from /lib64/ld-linux-x86-64.so.2
0x00007ffff7de429e in ?? () from /lib64/ld-linux-x86-64.so.2
0x00007ffff7de4523 in ?? () from /lib64/ld-linux-x86-64.so.2
0x00007ffff6cc612a in ?? () from /lib/x86_64-linux-gnu/libc.so.6
0x00007ffff7bd7044 in ?? () from /lib/x86_64-linux-gnu/libdl.so.2
0x00007ffff7de9176 in ?? () from /lib64/ld-linux-x86-64.so.2
0x00007ffff7bd752f in ?? () from /lib/x86_64-linux-gnu/libdl.so.2
0x00007ffff7bd709a in dlsym () from /lib/x86_64-linux-gnu/libdl.so.2
0x000000000041fd58 in main (argc=1, argv=0x7fffffffe1d8) at ../src/tpcc.cpp:141

I really don't understand what fails for the second query. I tried different flags for dlopen, but it didn't work for any combination.

Hope someone can help me, as I am very unexperienced in shared libraries.

Regards

moo
  • 486
  • 8
  • 22
  • So C or C++? It matters because of name mangling. –  Jan 02 '14 at 14:18
  • Just a guess - try adding the **-rdynamic** flag. – Brett Hale Jan 02 '14 at 14:34
  • It doesn't look like dynamic loading is relevant to the problem. Have tou tried to link the two part statically? That would eliminate one unknown. – n. m. could be an AI Jan 02 '14 at 14:46
  • How should I link them statically? The query is entered in the loop program, after that the query is translated and compiled to a shared library. This shared library is now dynamically loaded. As the library is generated in the loop, static linking is not possible. Which program must be compiled with the -rdynamic flag? The shared library with the query source code, I guess? – moo Jan 02 '14 at 14:48
  • -rdynamic flag does not help. I think the problem is related to a second occurence of a parallel_for loop! But I really don't understand it. It is C++, sorry! – moo Jan 02 '14 at 14:50
  • The issue may be related to using RTLD_GLOBAL when loading the library. It my be that symbols provided by the library are being falsely represented as already provided once you reload the .so. – Anya Shenanigans Jan 02 '14 at 14:50
  • I tried RTLD_LOCAL, too, but the problem still occurs – moo Jan 02 '14 at 14:51

3 Answers3

3

Try to replace

extern "C" { void run { ... } }

to

extern "C" void run { ... }

See explanation in the great http://www.isotton.com/devel/docs/C++-dlopen-mini-HOWTO/C++-dlopen-mini-HOWTO.html paper.

user2743554
  • 491
  • 2
  • 11
1

I am not really sure if what I am saying it is correct or not, but I remember had a simillar problem last year and I solved it generating the .so with the libraries included. Something like this:

g++ -O0 -g3 -fPIC -std=c++0x GeneratedQuery.cpp ../type/Types.cpp {add intel stuff here .a etc} -shared -o lib.so

I used CMAKE and I had to add to add_library stuff.

I hope this helps, if not apologies!.

Jose Palma
  • 756
  • 6
  • 13
0

Got it running, but I am still confused:

If I give each library file an other name, like lib..so and load it, everything works fine. Is there something like a cache which could lead to the described behaviour above?

moo
  • 486
  • 8
  • 22