You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@harmony.apache.org by "Gregory Shimansky (JIRA)" <ji...@apache.org> on 2007/08/02 16:54:53 UTC
[jira] Created: (HARMONY-4598) [classlib][luni] Loading "hyluni" in
java application results in broken classlib state
[classlib][luni] Loading "hyluni" in java application results in broken classlib state
--------------------------------------------------------------------------------------
Key: HARMONY-4598
URL: https://issues.apache.org/jira/browse/HARMONY-4598
Project: Harmony
Issue Type: Bug
Components: Classlib
Reporter: Gregory Shimansky
Priority: Minor
I've stumbled on this bug today when two of DRLVM tests started to fail on one linux workstation. These tests are on Runtime.load and Runtime.loadLibrary functions. They are made in the way that a test tries to lookup the first library in VM home and tries to load it. Sometimes it happens that the first library found in VM home is "hyluni". After this library is loaded into the test, classlib's state is broken because macro HARMONY_CACHE_GET starts to return NULL (e.g. for key CLS_array_of_byte). On J9 trying to load "hyluni" into Java applications results in premature program termination with exit code 1 and no diagnostics.
I know that tests that try to load a random library are not quite good, but in any case, this seems to be a valid java code.
I wrote a test that shows this bad behavior:
import java.io.*;
public class LF {
public static void main(String args[]) {
String path = args.length == 0 ? "./" : args[0];
File f = new File(path);
System.out.println("Try 1");
File[] files = f.listFiles();
for (int iii = 0; iii < files.length; iii++) {
System.out.println("File [ " + iii + " ] = " + files[iii]);
}
System.out.println("DONE 1");
System.loadLibrary("hyluni");
System.out.println("Try 2");
files = f.listFiles();
for (int iii = 0; iii < files.length; iii++) {
System.out.println("File [ " + iii + " ] = " + files[iii]);
}
System.out.println("DONE 2");
}
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (HARMONY-4598) [drlvm][classloader] Loading
"hyluni" in java application results in broken classlib state
Posted by "Gregory Shimansky (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Gregory Shimansky updated HARMONY-4598:
---------------------------------------
Priority: Major (was: Minor)
Environment: Linux on all architectures
I increased this bug priority since this bug is not as rare as I thought.
> [drlvm][classloader] Loading "hyluni" in java application results in broken classlib state
> ------------------------------------------------------------------------------------------
>
> Key: HARMONY-4598
> URL: https://issues.apache.org/jira/browse/HARMONY-4598
> Project: Harmony
> Issue Type: Bug
> Components: DRLVM
> Environment: Linux on all architectures
> Reporter: Gregory Shimansky
>
> I've stumbled on this bug today when two of DRLVM tests started to fail on one linux workstation. These tests are on Runtime.load and Runtime.loadLibrary functions. They are made in the way that a test tries to lookup the first library in VM home and tries to load it. Sometimes it happens that the first library found in VM home is "hyluni". After this library is loaded into the test, classlib's state is broken because macro HARMONY_CACHE_GET starts to return NULL (e.g. for key CLS_array_of_byte). On J9 trying to load "hyluni" into Java applications results in premature program termination with exit code 1 and no diagnostics.
> I know that tests that try to load a random library are not quite good, but in any case, this seems to be a valid java code.
> I wrote a test that shows this bad behavior:
> import java.io.*;
> public class LF {
> public static void main(String args[]) {
> String path = args.length == 0 ? "./" : args[0];
> File f = new File(path);
> System.out.println("Try 1");
> File[] files = f.listFiles();
> for (int iii = 0; iii < files.length; iii++) {
> System.out.println("File [ " + iii + " ] = " + files[iii]);
> }
> System.out.println("DONE 1");
> System.loadLibrary("hyluni");
> System.out.println("Try 2");
> files = f.listFiles();
> for (int iii = 0; iii < files.length; iii++) {
> System.out.println("File [ " + iii + " ] = " + files[iii]);
> }
> System.out.println("DONE 2");
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HARMONY-4598) [drlvm][classloader] Loading
"hyluni" in java application results in broken classlib state
Posted by "Gregory Shimansky (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12528033 ]
Gregory Shimansky commented on HARMONY-4598:
--------------------------------------------
I excluded two tests above at 576386. They started to fail on other machines for the same reason.
> [drlvm][classloader] Loading "hyluni" in java application results in broken classlib state
> ------------------------------------------------------------------------------------------
>
> Key: HARMONY-4598
> URL: https://issues.apache.org/jira/browse/HARMONY-4598
> Project: Harmony
> Issue Type: Bug
> Components: DRLVM
> Reporter: Gregory Shimansky
> Priority: Minor
>
> I've stumbled on this bug today when two of DRLVM tests started to fail on one linux workstation. These tests are on Runtime.load and Runtime.loadLibrary functions. They are made in the way that a test tries to lookup the first library in VM home and tries to load it. Sometimes it happens that the first library found in VM home is "hyluni". After this library is loaded into the test, classlib's state is broken because macro HARMONY_CACHE_GET starts to return NULL (e.g. for key CLS_array_of_byte). On J9 trying to load "hyluni" into Java applications results in premature program termination with exit code 1 and no diagnostics.
> I know that tests that try to load a random library are not quite good, but in any case, this seems to be a valid java code.
> I wrote a test that shows this bad behavior:
> import java.io.*;
> public class LF {
> public static void main(String args[]) {
> String path = args.length == 0 ? "./" : args[0];
> File f = new File(path);
> System.out.println("Try 1");
> File[] files = f.listFiles();
> for (int iii = 0; iii < files.length; iii++) {
> System.out.println("File [ " + iii + " ] = " + files[iii]);
> }
> System.out.println("DONE 1");
> System.loadLibrary("hyluni");
> System.out.println("Try 2");
> files = f.listFiles();
> for (int iii = 0; iii < files.length; iii++) {
> System.out.println("File [ " + iii + " ] = " + files[iii]);
> }
> System.out.println("DONE 2");
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (HARMONY-4598) [drlvm][classloader] Loading
"hyluni" in java application results in broken classlib state
Posted by "Gregory Shimansky (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Gregory Shimansky updated HARMONY-4598:
---------------------------------------
Summary: [drlvm][classloader] Loading "hyluni" in java application results in broken classlib state (was: [drlvm][luni] Loading "hyluni" in java application results in broken classlib state)
BTW I forgot to write which tests sometimes fail when hyluni is loaded into VM. These tests are drlvm kernel tests
java.lang.RuntimeTest
java.lang.SystemExtensionTest
They may be excluded if the bug manifests itself often enough.
> [drlvm][classloader] Loading "hyluni" in java application results in broken classlib state
> ------------------------------------------------------------------------------------------
>
> Key: HARMONY-4598
> URL: https://issues.apache.org/jira/browse/HARMONY-4598
> Project: Harmony
> Issue Type: Bug
> Components: DRLVM
> Reporter: Gregory Shimansky
> Priority: Minor
>
> I've stumbled on this bug today when two of DRLVM tests started to fail on one linux workstation. These tests are on Runtime.load and Runtime.loadLibrary functions. They are made in the way that a test tries to lookup the first library in VM home and tries to load it. Sometimes it happens that the first library found in VM home is "hyluni". After this library is loaded into the test, classlib's state is broken because macro HARMONY_CACHE_GET starts to return NULL (e.g. for key CLS_array_of_byte). On J9 trying to load "hyluni" into Java applications results in premature program termination with exit code 1 and no diagnostics.
> I know that tests that try to load a random library are not quite good, but in any case, this seems to be a valid java code.
> I wrote a test that shows this bad behavior:
> import java.io.*;
> public class LF {
> public static void main(String args[]) {
> String path = args.length == 0 ? "./" : args[0];
> File f = new File(path);
> System.out.println("Try 1");
> File[] files = f.listFiles();
> for (int iii = 0; iii < files.length; iii++) {
> System.out.println("File [ " + iii + " ] = " + files[iii]);
> }
> System.out.println("DONE 1");
> System.loadLibrary("hyluni");
> System.out.println("Try 2");
> files = f.listFiles();
> for (int iii = 0; iii < files.length; iii++) {
> System.out.println("File [ " + iii + " ] = " + files[iii]);
> }
> System.out.println("DONE 2");
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (HARMONY-4598) [drlvm][luni] Loading "hyluni" in
java application results in broken classlib state
Posted by "Gregory Shimansky (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Gregory Shimansky updated HARMONY-4598:
---------------------------------------
Component/s: (was: Classlib)
DRLVM
Summary: [drlvm][luni] Loading "hyluni" in java application results in broken classlib state (was: [classlib][luni] Loading "hyluni" in java application results in broken classlib state)
According to JNI spec [1] the same library cannot be loaded into more than one class loader. Since hyluni is already loaded into bootstrap class loader, it shouldn't be successfully loaded into system (or another) class loader that executes Java application.
Quick investigation with -Xtrace:classloader.native shows that first hyluni is loaded by short name into bootstrap class loader:
Loader (0x808c010) loaded native library: libhyluni.so
and then it is loaded using a long name with funny path
Loader (0x86f1be0) loaded native library: /nfs/ims/proj/drl/mrt2/users/gregory/gentoo/trunk/working_vm/build/lnx_ia32_gcc_debug/deploy/jdk/jre/bin//libhyluni.so
that is probably why it is allowed to be loaded the 2nd time - its name is not the same. So it looks like a bug in VMs. DRLVM shouldn't allow to load this library twice, J9 shouldn't exit silently.
[1] http://java.sun.com/j2se/1.5.0/docs/guide/jni/spec/invocation.html#library_version
> [drlvm][luni] Loading "hyluni" in java application results in broken classlib state
> -----------------------------------------------------------------------------------
>
> Key: HARMONY-4598
> URL: https://issues.apache.org/jira/browse/HARMONY-4598
> Project: Harmony
> Issue Type: Bug
> Components: DRLVM
> Reporter: Gregory Shimansky
> Priority: Minor
>
> I've stumbled on this bug today when two of DRLVM tests started to fail on one linux workstation. These tests are on Runtime.load and Runtime.loadLibrary functions. They are made in the way that a test tries to lookup the first library in VM home and tries to load it. Sometimes it happens that the first library found in VM home is "hyluni". After this library is loaded into the test, classlib's state is broken because macro HARMONY_CACHE_GET starts to return NULL (e.g. for key CLS_array_of_byte). On J9 trying to load "hyluni" into Java applications results in premature program termination with exit code 1 and no diagnostics.
> I know that tests that try to load a random library are not quite good, but in any case, this seems to be a valid java code.
> I wrote a test that shows this bad behavior:
> import java.io.*;
> public class LF {
> public static void main(String args[]) {
> String path = args.length == 0 ? "./" : args[0];
> File f = new File(path);
> System.out.println("Try 1");
> File[] files = f.listFiles();
> for (int iii = 0; iii < files.length; iii++) {
> System.out.println("File [ " + iii + " ] = " + files[iii]);
> }
> System.out.println("DONE 1");
> System.loadLibrary("hyluni");
> System.out.println("Try 2");
> files = f.listFiles();
> for (int iii = 0; iii < files.length; iii++) {
> System.out.println("File [ " + iii + " ] = " + files[iii]);
> }
> System.out.println("DONE 2");
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.