Go Premium for a chance to win a PS4. Enter to Win

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 934
  • Last Modified:

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"
0
Ryan Rowley
Asked:
Ryan Rowley
  • 5
  • 4
  • 2
  • +2
1 Solution
 
nebekerCommented:
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)
0
 
nebekerCommented:
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...
0
 
gadioCommented:
I also think that you should rebuild your libraries again with jdk1.3 header files.
0
Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
Ryan RowleyAuthor Commented:
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.


0
 
nebekerCommented:
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....
0
 
Ryan RowleyAuthor Commented:
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.
0
 
nebekerCommented:
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...)
0
 
Ryan RowleyAuthor Commented:
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.
0
 
Ryan RowleyAuthor Commented:
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.
0
 
Venci75Commented:
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
0
 
Ryan RowleyAuthor Commented:
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.
0
 
SpideyModCommented:
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
0
 
SpideyModCommented:
PAQ'd

SpideyMod
Community Support Moderator @Experts Exchange
0

Featured Post

Free Tool: ZipGrep

ZipGrep is a utility that can list and search zip (.war, .ear, .jar, etc) archives for text patterns, without the need to extract the archive's contents.

One of a set of tools we're offering as a way to say thank you for being a part of the community.

  • 5
  • 4
  • 2
  • +2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now