This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug dynamic-link/16805] dynamic library not getting reinitialized on multiple calls to dlopen()
- From: "safinaskar at mail dot ru" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Sat, 28 Feb 2015 17:40:35 +0000
- Subject: [Bug dynamic-link/16805] dynamic library not getting reinitialized on multiple calls to dlopen()
- Auto-submitted: auto-generated
- References: <bug-16805-131 at http dot sourceware dot org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=16805
--- Comment #7 from Askar Safin <safinaskar at mail dot ru> ---
This is real bug. Here is my testcase where this bug can cause very very
mysterious software failure.
I attached p.tar .
Steps to build and run:
flex --header-file=lex1.yy.hpp -o lex1.yy.cpp scanner1.lpp && flex
--header-file=lex2.yy.hpp -o lex2.yy.cpp scanner2.lpp && bison -do
parser1.tab.cpp parser1.ypp && bison -do parser2.tab.cpp parser2.ypp && g++
-shared -fPIC -o parser1.so -include lex1.yy.cpp parser1.tab.cpp && g++ -shared
-fPIC -o parser2.so lex2.yy.cpp parser2.tab.cpp && g++ main.cpp -ldl && ./a.out
In this example I build bison/flex c++ parser as "parser1.so" and then build
some another parser as "parser2.so"
The I load parser1 to main program and then unload it. The I load parser2 to
main program and run it. But it reports syntax error (and there really no any
syntax error). If you remove lines for loading parser1 you will see that
parser2 stops to report syntax error.
So, loading parser1 someway affects parser2.
Moreover, Tim Moloney said that this bug reproduces only if
class+inline+static. Okey, let's add some "sed" command to remove static var
from some inline function:
flex --header-file=lex1.yy.hpp -o lex1.yy.cpp scanner1.lpp && flex
--header-file=lex2.yy.hpp -o lex2.yy.cpp scanner2.lpp && bison -do
parser1.tab.cpp parser1.ypp && bison -do parser2.tab.cpp parser2.ypp && sed -i
's/^ *static$//' parser1.tab.cpp parser2.tab.cpp && g++ -shared -fPIC -o
parser1.so -include lex1.yy.cpp parser1.tab.cpp && g++ -shared -fPIC -o
parser2.so lex2.yy.cpp parser2.tab.cpp && g++ main.cpp -ldl && ./a.out
Now there is no bug. (And this is absolutely impossible to guess that one need
this "sed" hack.)
(I found this bug because I write some program which generates bison parsers in
run-time and then loads them. I have to add this "sed -i" hack to my program
because of this bug and this is the most hacky hack in my life)
My system is Debian GNU/Linux 8. glibc 2.19, gcc 4.9.1, flex 2.5.39, bison
3.0.2
--
You are receiving this mail because:
You are on the CC list for the bug.