Trying to locate function using dlfunc with RLTD_NEXT from JNI

[Matthieu Volat]

On Wed, 30 Nov 2016 15:00:36 +0200
Konstantin Belousov <kostikbel at gmail.com> wrote:

> On Wed, Nov 30, 2016 at 11:59:20AM +0100, Matthieu Volat wrote:
> > Hi, a (maybe not) tricky question for people who know well the internals of the jdk on freebsd...
> > 
> > Trying to port a linux project that does quite a bit of introspection, begining by using malloc & co wrapper, with java binding, I found that strangely, you can use dlfunc(RTLD_NEXT, "malloc") in a non-java environment... But as soon as this code is loaded in the context of the jvm, the symbol won't be resolved.
> > 
> > This is maybe a bit suprising as this technique worked on Linux and I did not expect much difference here...
> > 
> > Small demonstration code:
> > 
> >   % git clone https://gist.github.com/f6993d7a48ecbab6c0c979b9a7a40912.git jni_dlfunc
> >   % cd jni_dlfunc
> >   % make
> >   [...]
> >   % ./testfoo 
> >   malloc function located at 0x800ade210
> >   % java -Djava.library.path=. testfoo
> >   could not locate function malloc: Undefined symbol "malloc"
> > 
> > Would anybody have an idea of why the jvm would cause the C symbols not to be found via RTLD_NEXT and if there would be a way to workaround it (that is not to load explicitely "/lib/libc.so.7")?
> > 
> It does not work because libc.so is loaded before your dso in the global
> dso order.  Look carefully at the description of the RTLD_NEXT constant.
> 
> Why cannot you use RTLD_DEFAULT special there ?

Thanks. RTLD_DEFAULT would find the wrapper function and so the program would enter a loop of malloc() calling itself.

I was less suprised by the result than by the different behavior between java/linux and java/freebsd in that case... They must be doing some reordering I guess...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-java/attachments/20161130/3ddbffee/attachment.sig>