dlopen(0,0) loops

[Paul Goslin Rae McCarth]

I am trying to pre-load the 1.4.1 java virtual machine using LD_PRELOAD_ONCE=libjvm.sl. This seems to work, however, in order to access the symbols we need a handle returned from dlopen(). The man page on dlopen indicates that the symbols of pre-loaded libraries are loaded into the global symbol space and that passing 0 for the file name parameter of dlopen will return a handle to the global symbol space. Unfortunately, this causes dlopen to loop.

[Mark Greene_1]

Have you tried invoking dlopen with the mode set to RTLD_NOW?

mark

[Paul Goslin Rae McCarth]

I just tried it and it loops too.

[Mike Stroyan]

You could skip dlopen and use
dlsym(RTLD_DEFAULT,name);

That picks up shared library symbols.

Or you could try calling dlopen with "libjmv.sl". It should be good natured about returning a handle for an already loaded shared library.

[Paul Goslin Rae McCarth]

OK, I tried calling dlopen with libjvm.sl again and verified that it returns a file handle of 0, which causes dlsym(handle, ...) to return NULL.

I also tried skipping the dlopen and using RTLD_DEFAULT as the handle parameter in dlsym. This returned NULL for the symbol address also.

[Mike Stroyan]

Well...
It is time to verify that you have the latest
"ld(1) and linker tools cumulative patch". That patch includes the dld.sl shared library that implements dlopen and dlsym. The most recent patches are-
11.00 PHSS_28869
11.11 PHSS_28871

[Paul Goslin Rae McCarth]

Yes, PHSS_28869 is applied.

[ranganath ramachandra]

hi,

im in the PA linker/loader team. i didnt see this problem with a simple test case attached. let me know if it passes in your enviroment.

the 64-bit version ran into a problem that the jvm dumped core while trying to parse the arguments to JNI_CreateJavaVM. i'll talk to the jvm folks about this.

ranga

[Paul Goslin Rae McCarth]

Well... The test program works fine. I can duplicate the hang problem by linking certain shared libraries with the test program, even though the test program doesn't call into the library. Not all libraries cause the problem. I am currently trying to figure out what is unique about the libraries that cause the problem. If you have any ideas please let me know. The libraries are hard to tear apart because they are all inter-connected. I tried a simple hello world program in a library and it worked fine. When I have something new I'll post it. Thanks for your help so far.

[Paul Goslin Rae McCarth]

I've just discovered the problem. We have a library that contains a module that uses shl_load and contains hand coded dlopen, dlclose and dlsym entry points. dlopen() is coded as follows:

# include
void *dlopen (const char *filename, int flag) {
void *handle;
handle=shl_load(filename,
BIND_NONFATAL |
BIND_DEFERRED |
DYNAMIC_PATH,
0L);
return handle
}

I will reconfigure the shared library to use dlfcn.h and dlopen() etc.

Thanks for your help.