Dotaz: segfault: dlopen modulu v c++, main je v c

[vencas]

Zdravím, narazil jsem na zajímavý problém.

Hlavní program v c volá dlopen na .so, které je přeloženo z c++. Vytáhne si z něj funkci (deklarovanou extern "C" pochopitelně), zavolá ji. V té funkci se jen vypíše std::cerr<<"foo". To normálně funguje, dokud se k .so souboru nepřilinkuje nějaká jiná knihovna (odzkoušeno gomp nebo GL), pak to segfaultuje kdesi v libstdc++ (ostream); Přitom když se přeloží hlavní program pomocí g++, funguje to bez problémů.

Reportoval jsem to na ubuntí bugzillu, ale totéž se děje na debianu (lenny). Nevíte někdo co s tím? Nevím ani pořádně, jestli je to chyba libstdc++ nebo linkeru. Předpokládám, že půjde o nějakou statickou inicializaci čehosi, která se při dlopen neprovede? Přikládám kousky programů (ze zmíněného bugreportu).

main.c:

#include<dlfcn.h>
int main(void){
 void* handle=dlopen("./libfoo.so",RTLD_NOW);
 void(*foo)()=(void(*)())dlsym(handle,"foo");
 foo();
 return 0;
}

foo.cc:

#include<iostream>
extern "C" {
 void foo() { std::cerr<<"foo"<<std::endl; }
}

Takhle to padá:

$ g++ foo.cc -o libfoo.so -fPIC -rdynamic -shared
$ gcc main.c -o main -ldl
$ ./main
foo
$ g++ foo.cc -o libfoo.so -fPIC -rdynamic -shared -lgomp   ## navíc -lgomp  →  spadne
$ ./main
foozsh: segmentation fault (core dumped) ./main
$ g++ main.c -o main -ldl                                  ## main se kompiluje g++ místo gcc  →  nespadne
$ ./main
foo
$

A tohle mi prozrazuje gdb po pádu (při kompilaci s -g a použití libstdc++6-dbg):

(gdb) bt
#0 0x00007f81582c9e49 in std::uncaught_exception () at ../../../../src/libstdc++-v3/libsupc++/eh_catch.cc:136
#1 0x00007f8158294e04 in ~sentry (this=0x7fff3c47bbc0, __in_chrg=<value optimized out>) at /build/buildd/gcc-4.4-4.4.1/build/x86_64-linux-gnu/libstdc++-v3/include/ostream:408
#2 0x00007f8158295445 in std::__ostream_insert<char, std::char_traits<char> > (__out=..., __s=0x7f81590cf3be "foo", __n=3)
    at /build/buildd/gcc-4.4-4.4.1/build/x86_64-linux-gnu/libstdc++-v3/include/bits/ostream_insert.h:110
#3 0x00007f815829502e in std::operator<< <std::char_traits<char> > (__out=..., __s=0x7f81590cf3be "foo")
    at /build/buildd/gcc-4.4-4.4.1/build/x86_64-linux-gnu/libstdc++-v3/include/ostream:510
#4 0x00007f81590cf2e6 in foo () at foo.cc:3
#5 0x00000000004003a2 in main () at main.c:5

Co by s tím mohlo být? Díky moc.

Odpovědi

[Ivan]

Ahoj, asi ti moc nepomuzu cely je to nejaky divny. Na Ubuntu 9.10 se to chova presne jak jsi popisoval. Podobnou vec jsem videl kdysi na glic 2.1. Tehdy knihovna pthread obsahovala vlastni implementaci open a close. Sockety otevreny pres thread-safe open nesly zavrit pomoci normalniho close. Jediny reseni tehdy bylo pouzit LD_PRELOAD=/usr/lib/libpthread.so. To uz ale dneska neni potreba.
/tmp$ ./main
fooSegmentation fault
$ LD_PRELOAD=/usr/lib/libgomp.so.1 ./main
foo
Vypada to, ze ta knihovna libgomp nema rada kdyz se nahrava pres dlopen. Ve vypisu nm knihovny libgomp neni nic podezrelyho. Zkusil jsem ten main zkompilovat s -lpthread a ani to nepomohlo. Jediny co by se s tim jeste dalo delat je kouknout se na .init sekci ty knihovny libgomp pres readelf. Ivan

[Ivan]

http://gcc.gnu.org/ml/gcc-help/2007-04/msg00307.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28482 NOOPEN flag - doted jsem netusil ze neco takovyho existuje.

[vencas]

Díky za postřehy, vedle gomp to dělá taky GL (nvidie), a možná další, které jsem nezkoušel. Stálo by to za nahlášení do bugzilly přímo na gnu.org? Trochu se děsím toho, že mi napíšou, že to je proboém debianu, ať to zkusím na neopatchované verzi etc.

[vencas]

Ehm, pardon, ATI. Zajímavé odkazy; tehdy to vůbec nešlo dlotevřít. To teď funguje, jen cerr padá (jiné funkce: i/o, výpočty etc, fungují spolehlivě).

[Sinuhet]

Pokud k modulu rucne prilinkuji libsupc++, tak ta sranda funguje.

$ g++ foo.cc -o libfoo.so -fPIC -rdynamic -shared -lgomp -lsupc++

[vencas]

libsupc++ na debianu vůbec neexistuje (vygoogloval jsem jen málo a většinou starého)... na čem jedeš? Tady gcc-4.4

Zjistil jsem však, že funguje

$ LD_PRELOAD=/usr/lib/libstdc++.so.6 ./main
foo
$

Main (což je ve skutečnosti python) tedy musím obalit skriptem, ale to zase tolik nevadí.

[vencas]

A dokonce stačí udělat dlopen("/usr/lib/libstdc++.so.6",RTLD_LAZY); před otevřením modulu a funguje to taky!!

Myslíte že mám nahlásit bug? Aspoň by tuhle prasárnu mohli zdokumentovat.