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 17:16:52 UTC

[jira] Updated: (HARMONY-4598) [drlvm][classloader] Loading "hyluni" in java application results in broken classlib state

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