Link to home
Start Free TrialLog in
Avatar of Ryan Rowley
Ryan RowleyFlag for United States of America

asked on

System.loadLibrary() core dump

I've just been handed this problem to look at.
I'm looking for some comments and suggestions on this.
I'm trying to decide what actions I need to take.

Thanks


JAVA/Solaris related.

In a nutshell, we have been attempting to use JAVA 1.3.0 and/or 1.3.1 on Solaris 2.8 wanting to upgrade from the JAVA 1.2.X versions. Thing is, we are unsuccessful in attempts to run on the 1.3.X versions due to the VM process aborting:

Example:
{hyperion}19%java LoadLib
Before Load Lib...
Abort (core dumped)

After running with truss it appears that the problem occurs during the loading of one of our shared libraries. Thus I created a new test, LoadLib, which only calls System.loadLibrary("ourlib") and immediately fails with the core dump.

I have added the required Solaris 2.8 patches specified by the JAVA installation documents and thing are still not working.

This behavior is strange to say the least since we can run successfully with the 1.2.x versions and NOT the 1.3.x versions.

Anyone have an issue with loadLibrary of the sort or have a clue what may be happening?

More Information:
I can compile and link my libs on Solaris 2.8 with JDK 1.2.x and everything works fine.

The call to System.loadLibrary() subsequently "core dumps" deep within the call stack of a JVM native method call, so there wouldn't be an exception to catch. You can check it out yourself, I've included the call stack I get from dbx.

The LD_LIBRARY_PATH is set properly.


Here is the class which gets run:

public class LoadLib {

static {
System.out.println("LD_LIBRARY_PATH=" + System.getProperty("java.library.path"));
System.out.println("Before Load Lib...");
try {
System.loadLibrary("com_devkit");
}
catch (Throwable t) {
System.out.println("Caught this..." + t.toString());
t.printStackTrace(System.out);
}

System.out.println("After Load Lib...");
}

public static void main (String[] args) {
System.out.println("Done!");
}
}

Here is the stack from "dbx":
Exception of type int {assumed} is unexpected
t@1 (l@4) stopped in __exdbg_notify_of_unexpected at 0xfefd5c84
0xfefd5c84: __exdbg_notify_of_unexpected : jmp %o7 + 0x8
Current function is JNIEnv_::FindClass
758 return functions->FindClass(this, name);
(/vobs/Solaris_tools/FD60/SUNWspro/WS6/bin/sparcv9/dbx) where
current thread: t@1
---- hidden frames, use 'where -h' to see them all ----
[3] __SLIP.INIT_A(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xf48135f0
[4] __STATIC_CONSTRUCTOR(0xf4812f74, 0x0, 0xffe4b108, 0xff3e3728, 0x23664, 0xf4863a94), at 0xf4814840
[5] _init(0x0, 0xff3e260c, 0x1, 0xff3e260c, 0x178f8, 0x0), at 0xf4863e78
[6] call_init(0xf4863a68, 0x0, 0xff3e21e0, 0xff3e260c, 0x0, 0x400000), at 0xff3ba730
[7] dlmopen_intn(0xfed01514, 0xfa250, 0xc01, 0xfee716f4, 0x0, 0xc01), at 0xff3be09c
[8] _dlopen(0xfa250, 0x1, 0xfa250, 0x0, 0x0, 0x0), at 0xff3be17c
[9] sysLoadLibrary(0xfa250, 0xffbed2a8, 0x400, 0xffbec, 0xff2f3b44, 0xffbece2c), at 0xfecd8b20
[10] JVM_LoadLibrary(0xfa250, 0xff306ce8, 0x24940, 0xff2f3b44, 0xfa250, 0xf4c24a14), at 0xff101e48
[11] Java_java_lang_ClassLoader_00024NativeLibrary_load(0x90c68, 0xfa250, 0xff38257c, 0xff3810b8, 0x249c4, 0xffbed900), at 0xff35bc10
[12] 0x6ba20(0xf4c24a90, 0xffbedc68, 0x24940, 0xff2f3b44, 0xb6, 0xf8c35930), at 0x6ba1f
[13] 0x68ba4(0xf4c247a8, 0xf8c684f0, 0xf4c23dc8, 0x71c28, 0xf4e00000, 0xf8c35810), at 0x68ba3
[14] 0x68be8(0x24940, 0xffbedc68, 0x24940, 0x73f60, 0xb8, 0xf8ca2450), at 0x68be7
[15] 0x68ba4(0xf4c23dc0, 0xffbedc68, 0x24940, 0x71dc8, 0xb6, 0xf8c3b558), at 0x68ba3
[16] 0x68ba4(0x24940, 0xffbedc68, 0x24940, 0x71c28, 0xb8, 0xf8ca0c28), at 0x68ba3
[17] 0x68ba4(0x0, 0x1, 0xff2ffd78, 0x71dc8, 0x1e, 0xe), at 0x68ba3
[18] 0xff324994(0xffbedc88, 0xffbeddc8, 0xa, 0xf8ca0a60, 0x6abec, 0xffbeddd4), at 0xff324993
[19] JavaCalls::call_helper(0xffbeddc0, 0xff2f3b44, 0xffbeddd0, 0x24940, 0x6abec, 0xffbeddc8), at 0xff0c9d3c
[20] JavaCalls::call(0xffbeddc0, 0xffbeddbc, 0xffbeddd0, 0x24940, 0x24f50, 0xffbedd2c), at 0xff0c99e8
[21] instanceKlass::call_class_initializer_impl(0xf8ca0a60, 0x24940, 0xf8c01c88, 0xf8ca0ad8, 0xff2f3b44, 0xffbede04), at 0xff0928ec
[22] instanceKlass::initialize_impl(0xffbedff0, 0xf8ca0ad8, 0xff2f3b44, 0x24940, 0x3, 0xf8c02f10), at 0xff090ce8
[23] instanceKlass::initialize(0xf8ca0ad8, 0x24940, 0x21da0, 0x1, 0x24940, 0xffbee07c), at 0xff08f848
[24] find_class_from_class_loader(0xf8ca0ad8, 0x249c4, 0x1, 0xffbee0e4, 0xffbee0e0, 0x1), at 0xff103e84
[25] jni_FindClass(0xf8c77100, 0x0, 0x249c4, 0x24940, 0x1124c, 0xff2f3b44), at 0xff0cf808
=>[26] JNIEnv_::FindClass(this = 0x249c4, name = 0x1124c "LoadLib"), line 758 in "jni.h"
[27] main(argc = 1, argv = 0xffbee2dc), line 52 in "simpVMtest.cpp"
Avatar of nebeker
nebeker

Did you remove the Java 1.2 installation, or is it co-existing with the 1.3 installation?  If so, is the JAVA_HOME environment variable set?

What do you get when you call:

whence java  
 -or-
which java

(depends on your shell, I think)
Also, did you recompile/rebuild your library with the header files shipped with 1.3?  I don't know if there were any changes between the 1.2 and 1.3 versions - but it might be something to check...
I also think that you should rebuild your libraries again with jdk1.3 header files.
Avatar of Ryan Rowley

ASKER

This program is tested on freshly loaded and confiquered
Sun Ultras. These systems are only used for testing.


This program runs successfully on:
     Solaris 7
     Windows 2000
     Redhat Linux 7.2
     AIX

It Fails only on Solaris 8.

When the .so is accessed it cores.


Personally, I think it is more important to know if the .so was recompiled with the 1.3 headers than having it work as-is on those other platforms....
nebeker,
I believe that it has been, but I'm going to comfirm that
it has myself. I was told that they did recompiled everything with the 1.3 headers and the latest release of compilers.
After confirming the recompile, can you also check to see if Java 1.2 is still on the Solaris 8 box?  If it is, which version of java is in your path?  (i.e. "which java" will tell you where it is coming from, and "java -version" will tell you which version is actually loading...)
As I suspected they could not confirm that everything was compiled using the newer headers. I'm reloading a machine from scratch and recording every installed patch and will rebuild everything.  

The testing machines are loaded from scratch and only have JAVA 1.3 on them.

This program runs with no problems under JAVA 1.2.
I'm going to test it under JAVA 1.4 to see if the problem carries over.

I'm having more hardrive space installed on my local Sun Ultra. It will give me the ability to build everything on my local machine and eliminate some of the varables.
Do to another project needing my experience in embeded avionics systems (DoD project). I have handed off this problem to someone else. I have no way to verify a solution at this time.
No comment has been added lately, so it's time to clean up this TA.
I will leave a recommendation in the Cleanup topic area that this question is:
Answered by: nebeker
Please leave any comments here within the next seven days.
 
PLEASE DO NOT ACCEPT THIS COMMENT AS AN ANSWER!
 
Venci75
EE Cleanup Volunteer
Nebeker's comments didn't fix the problem.
I suspect the comments here would be useful to fixing other problems. I'm going to call over to the other office to see if they have found a fix yet.
Will return in 7 days to finalize this if it hasn't taken place.  Please leave any recommendations there before then.  Without recommendations I will PAQ with no refund.  Thanks.


SpideyMod
Community Support Moderator @Experts Exchange
ASKER CERTIFIED SOLUTION
Avatar of SpideyMod
SpideyMod

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial