harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gregory Shimansky (JIRA)" <j...@apache.org>
Subject [jira] Updated: (HARMONY-4598) [drlvm][luni] Loading "hyluni" in java application results in broken classlib state
Date Thu, 02 Aug 2007 15:07:53 GMT

     [ 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.


Mime
View raw message