This is the mail archive of the
libstdc++@sources.redhat.com
mailing list for the libstdc++ project.
Re: Q: libio and stream in stdc++
- To: Benjamin Kosnik <bkoz at redhat dot com>
- Subject: Re: Q: libio and stream in stdc++
- From: Levente Farkas <lfarkas at mindmaker dot hu>
- Date: Tue, 31 Oct 2000 18:48:16 +0100
- Cc: STDC++ <libstdc++ at sources dot redhat dot com>,Dietmar Kuehl <dietmar_kuehl at yahoo dot com>
- Organization: Mindmaker Ltd.
- References: <Pine.SOL.3.91.1001027061222.13532A-100000@cse.cygnus.com>
- Reply-To: lfarkas at mindmaker dot hu
Benjamin Kosnik wrote:
>
> > so I've to track down the dlopen (aka. java's System.Loadlibrary bug).
> > finaly it's turn out that the problems comes from this stack trace:
> > ------------------
> > std::ios_base::Init::Init(void)
> > std::basic_filebuf<char, std::char_traits<char> >::basic_filebuf(int, char const
> > *, std::_Ios_Openmode)
> > std::__basic_file<char>::sys_open(int, std::_Ios_Openmode)
>
> Note that this is a non-standard ctor....
>
> Levente, I've not been paying attention to this thread.
> Can you back up a bit and give me a pointer to code that shows what you
> are trying to do?
sorry for the delay, but my car was broken, I had to find a multicast udp
linux kernel bug and comdex is very close:-(
so the story again. now I put together a simple demo example for you.
unfortunately I can't show you the problem without java, but it'll turn
out that this bug has nothing to do with java or at least it's a v3 bug.
I attached the sources, each of a few lines of code.
Let we have a simple java class defining a native method. We have to
implement it in c or c++, compile it, make a shared library and run the
java code.
What DynamicLoader.java does is only loading the library and
calling the native function (sleep before and after the library load to
see what's happening!). I hope this example is understandable for everyone even
for those not knowing java.
java compiling goes with
----------------------
javac DynamicLoader.java
----------------------
set the current library to the CLASSPATH and generate the c header file
for native function with:
----------------------
export CLASSPATH=<current dir>
javah DynamicLoader
----------------------
I include a precompiled DynamicLoader.class and DynamicLoader.h for you
if you don't would like to do it.
the native.c is a simple implementation of the afunc.
compile it with (from now on suppose java's include directory is in
/usr/local/IBMJava2-13/include or you have to change it in the gcc
argument list):
----------------------
gcc -fPIC -c -I/usr/local/IBMJava2-13/include native.c
----------------------
create the shared library with:
----------------------
gcc native.o -shared -Wl,-soname,libnative.so.1 -o libnative.so.1.0
----------------------
create a few symlink and add the current library to the LD_LIBRARY_PATH
----------------------
ln -s libnative.so.1.0 libnative.so.1
ln -s libnative.so.1.0 libnative.so
export LD_LIBRARY_PATH=<current dir>
----------------------
and run the java code:
----------------------
java DynamicLoader
----------------------
everything works fine!!! :-) the file 'afile' created and...
now the bad part. try to implement the native function in c++ that's what
can be seen in the native.cpp. compile and link it:
----------------------
gcc -fPIC -c -I/usr/local/IBMJava2-13/include native.cpp
gcc native.o -lstdc++ -shared -Wl,-soname,libnative.so.1 -o libnative.so.1.0
----------------------
than run the java code again:
----------------------
java DynamicLoader
----------------------
the java vm will go wild: produces stacktrace in an infinite loop:-(
the good and bad news, since I didn't tell you which version of stdc++ is the
-lstdc++ :-) if you do it with stdc++ v2 or STLport everything working with
the native c++ code, but if you try it with v3 than you can get the above
mentioned crash. so it's obvious the bug in v3.
then I track down the problem and that was my previous letter:
http://sources.redhat.com/ml/libstdc++/2000-10/msg00221.html
(I've to include it here but it's easier:-)
and it seems there is a bug in
std::__basic_file<char>::sys_open(int, std::_Ios_Openmode)
during shred library loading (when static members are initialized)
and in
std::basic_filebuf<char, std::char_traits<char> >::close(void)
when I comment out std::ios_base::Init::Init(void).
a few more addon:
if you try to call 'afunc' from a c program, this is the main.c everything
works well even with v3.
compile and run:
----------------------
gcc -c -I/usr/local/IBMJava2-13/include main.c
gcc main.o libnative.so -o main
./main
----------------------
now load the libnative.so dynamicaly from a c code this is the main_dl.c:
----------------------
gcc -c -I/usr/local/IBMJava2-13/include main_dl.c
gcc main.o libnative.so -o main
./main
----------------------
it's sill working with v3 ! ?
so what can be the problem ? the only assumption is that the java vm is
staticaly linked with 'an' stdc++ library, I assume with an older v2,
but I don't have any further tipp. I assume these small examples are
so obvoius that we have to find the bug!
if anybody need any furter info I try to help.
-- Levente
"The only thing worse than not knowing the truth is
ruining the bliss of ignorance."
DynamicLoader.java
native.c
native.cpp
main.c
main_dl.c
DynamicLoader.h
DynamicLoader.class