Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: domain of alexey.v.varlamov@gmail.com
 designates 66.249.82.195 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=LTx04sFwHM62T9TFm24znKTd7GCxQJ7dqAat+zEF5HO2361xqQSOvwIz9O3VkoIeHevzdiAIw6VerlzX94vlIpfdMTWxOw9RTSscZA+d23OXMCNOJlp22F73MnK8MsQnGXsCP1wb0SCQ1TqPpbSUFZpQhpZFOW0T92bzwKFEd7A=
Message-ID: <f944d83d0607050156i7357bb63w9253e2c33a971bbb@mail.gmail.com>
Date: Wed, 5 Jul 2006 15:56:11 +0700
From: "Alexey Varlamov" <alexey.v.varlamov@gmail.com>
To: harmony-dev@incubator.apache.org
Subject: Re: [drlvm] Signed jars cannot be used in classpath
In-Reply-To: <200607050400.35464.gshimansky@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <200607010259.50768.gshimansky@gmail.com>
	 <44A98FDE.9030603@gmail.com>
	 <f944d83d0607040300l88b3ab3i7afa457473a497a7@mail.gmail.com>
	 <200607050400.35464.gshimansky@gmail.com>

Gregory,

I also was stumbled by this failure, especially as the VM provides
scanty diagnostics about it's reason:

<console.log>
*** Error: exception occured in main Thread constructor.
JNI.ExceptionDescribe: java/lang/ExceptionInInitializerError:

java/lang/ExceptionInInitializerError : (null)
ERROR: Destructive unwinding: C++ objects detected on stack!
  droping 0x0012F3A4
 setting curr 0x0012F51C
</console.log>

But the stack trace you managed to obtain (how did you, BTW?) prompted
me an extra bootstrap dependency in the j.l.ClassLoader which must be
fixed. Namely, there is a field "defaultDomain", which is incorrectly
initialized in static block, rather than be created lazily as API
specification requires (see javadoc for defineClass(String, byte[],
int, int, ProtectionDomain) ).

--
Regards,
Alexey Varlamov

> It looks like the most recent changes to classlib in file operations created
> an unresolved bootstrap dependency if security/ directory with its rules and
> policies is copied from classlib's lib/ to drlvm lib/ directory. In this case
> security cannot initialize correctly because the field
> FileInputStream.fileSystem is null at the moment when it is needed. Stack
> trace looks like this:
>
> ****** STACK DUMP: ************
> java/io/FileInputStream.<init>(Ljava/io/File;)V (FileInputStream.java:66)
> java/security/Security$1.run()Ljava/lang/Object; (Security.java:113)
> java/security/AccessController.doPrivilegedImpl(Ljava/security/PrivilegedAction;Ljava/security/AccessControlContext;)Ljava/lang/Object;
> (NULL:-1)
> java/security/AccessController.doPrivileged(Ljava/security/PrivilegedAction;)Ljava/lang/Object;
> (NULL:-1)
> java/security/Security.<clinit>()V (Security.java:116)
> org/apache/harmony/security/fortress/PolicyUtils$SecurityPropertyAccessor.run()Ljava/lang/String;
> (PolicyUtils.java:148)
> org/apache/harmony/security/fortress/PolicyUtils$SecurityPropertyAccessor.run()Ljava/lang/Object;
> (PolicyUtils.java:127)
> java/security/AccessController.doPrivilegedImpl(Ljava/security/PrivilegedAction;Ljava/security/AccessControlContext;)Ljava/lang/Object;
> (NULL:-1)
> java/security/AccessController.doPrivileged(Ljava/security/PrivilegedAction;)Ljava/lang/Object;
> (NULL:-1)
> java/security/Policy.getDefaultProvider()Ljava/security/Policy;
> (Policy.java:150)
> java/security/Policy.getAccessiblePolicy()Ljava/security/Policy;
> (Policy.java:195)
> java/security/Policy.getPolicy()Ljava/security/Policy; (Policy.java:131)
> java/lang/ClassLoader.<clinit>()V (NULL:-1)
> java/lang/Class.desiredAssertionStatus()Z (NULL:-1)
> java/util/HashMap.<clinit>()V (HashMap.java:27)
> org/apache/harmony/luni/platform/AdapterManager.<init>()V
> (AdapterManager.java:34)
> org/apache/harmony/luni/platform/Platform.<clinit>()V (Platform.java:34)
> java/io/FileOutputStream.<init>(Ljava/io/FileDescriptor;)V
> (FileOutputStream.java:119)
> java/lang/System.createErr()Ljava/io/PrintStream; (NULL:-1)
> java/lang/System.<clinit>()V (NULL:-1)
> java/lang/Thread.<init>(Ljava/lang/ThreadGroup;Ljava/lang/Runnable;Ljava/lang/String;J)V
> (NULL:-1)
> java/lang/Thread.<init>()V (NULL:-1)
>
> At first I was curious as to why FileInputStream.<clinit> is not in the stack,
> but I did bytecode dump and found that Sun's javac 1.5 optimized <init>
> methods to include <clinit> code into them. So it included line
>
> private IFileSystem fileSystem = Platform.getFileSystem();
>
> into constructor's code and so the value of IFileSystem FILE_SYSTEM from
> Platform was returned. But since Platform.<clinit> is clearly in the stack,
> Platform's <clinit> was not finished yet by that time. Dumping bytecode for
> compiled Platform shows that line 34 is really the assignment of constant
> NETWORK_SYSTEM which turns out to be null later down the stack.
>
> This is a quite fundamental problem with classlib's bootstrap and we don't
> have any defined bootstrap sequence. When something is initialized in
> <clinit> there is no way to be 100% sure it is really initialized in many
> classes which are commonly used because <clinit> is called only once and
> bootstrap recursion may get to call some methods of a class before <clinit>
> actually completes. The workaround for this is instead of using
>
>    Whatever WHATEVER1 = Something.something();
> or
>
>    Whatever WHATEVER2 = new Whatever();
>
> do the following
>
>    method() {
>        if (WHATEVER1 == null)
>            WHATEVER1 = Something.something();
>
>        if (WHATEVER2 == null)
>            WHATEVER2 = new Whatever();
>    }
>
> but this is ugly, inefficient and my in theory turn classlib bootstrap into
> infinite recursion.
>
> I don't know a general solution for this. The order of class resolution, java
> compiler optimizations and other factors may affect the bootstrap sequence.
>
> --
> Gregory Shimansky, Intel Middleware Products Division
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org