android on X86 will not boot after June 22nd

[Yi Sun]

All,
If you have a tree that is checked out from google after June 22nd,  you may not be able to run it with X86. Your package manager service may crash during the system boot up and when Android tries to load frameworks_res.jar (I may remember the file name wrong). Chih-wei found that rolling back dalvik changes eac47eddd953ca572f1c92a326b55b735b46377d will solve the problem. So if you hit on the same problem, you can try to roll back this change.

Yi
http://code.google.com/p/patch-hosting-for-android-x86-support/

[Chen Yang]

just curious to know: is the arm version working correctly?

From what i have observed on x86, the introduced code by that patch brought none reference stuff as reference, which caused the runtime segmentation fault.

[fadden]

On Jul 7, 10:41 am, Chen Yang <sunsety...@gmail.com> wrote:
> just curious to know: is the arm version working correctly?
> From what i have observed on x86, the introduced code by that patch brought
> none reference stuff as reference, which caused the runtime segmentation
> fault.

We don't see a segmentation fault here, though it does fail to start
up on the ARM emulator (some keystore problem).

Do you have a native stack trace from the core dump?

[Chen Yang]

Fadden:

  Thanks.

I don't have it at present.

Is there some good approach for generating the native stack trace? It seems in my case, it just aborts and restarts the zygote again and again.

 

From what I have observed, it dumped some weird value as reference, the value doesn't belong to any dalvik heap.

one case I remembered:

IS_CLASS_FLAG_SET(clazz, CLASS_ISARRAY) in scanObject: caused segfault

Any plan to introduce the precise GC soon? Thanks.

--

Chen

[Yi Sun]

It does not give me a trace at all. The dalvik only reports a process exit by sig 11.

[barry]

There seem to be two problems under discussion in this thread. One is
a "native stack trace" and the other is the keystore problem Fadden
mentions, in a non-public merge. Both go away with the rollback. I
don't think anyone at Google has a good handle on what the "native"
problem is; I don't think it's been seen there. It's pretty suspicious
that they both go away when this one change is rolled back.

Patching the suspect CL into the current Donut candidate seems to
work, or at least not crash quickly. Taking the merged code [with the
keystore issue] and if'fing out the actual use of the bitmap makes the
bug no longer manifest. Even if this code isn't at fault, it's
certainly tickling something else that I don't understand. I'm willing
to trade theories. Unfortunately, I have a few other things to do, and
then vacation coming up, so won't have time to be in on the hunt until
I get back.

Donut can't have the exposure to risk that this CL presents, so this
CL won't be in donut, unless we figure out the actual cause really
soon, and it's really clear, and even then, probably not. Donut is in
"bugfix only" right now, and shouldn't be cracked for this CL.

[Yi Sun]

On Tue, Jul 7, 2009 at 12:20 PM, barry <bha...@gmail.com> wrote:

There seem to be two problems under discussion in this thread. One is
a "native stack trace" and the other is the keystore problem Fadden
mentions, in a non-public merge. Both go away with the rollback. I
don't think anyone at Google has a good handle on what the "native"
problem is; I don't think it's been seen there. It's pretty suspicious
that they both go away when this one change is rolled back.

 
I thought the stack trace is printed by debuggerd, right? X86 does not  have it. Will this be the reason?

[Yi Sun]

FYI--I just made a gdbserver for Android on X86. It is in http://patch-hosting-for-android-x86-support.googlecode.com/files/gdbserver

[fadden]

bhayes has posted an explanation of the problem in the change (https://
review.source.android.com/#change,10482).

In short, it can cause live objects to be collected.

[Yi Sun]

Ok, if anyone have a patch, I can test it out for you

[Chen Yang]

Cool!

Any explanation on why it doesn't show on ARM platform?

--

Chen 

[fadden]

On Jul 9, 1:13 am, Chen Yang <sunsety...@gmail.com> wrote:
> Any explanation on why it doesn't show on ARM platform?

It does -- it comes down to timing and luck. If you have a class that
creates an instance of itself during class initialization, and a GC
happens before class init completes, you will likely have some trouble
later on.

[Chen Yang]

how about moving the computation of refOffsets to dvmLinkClass, after the precacheReferenceOffsets is done?

I have made one improvement for current code which avoid one problem on x86, and I have passed verification in kvm.

 

diff --git a/vm/oo/Class.c b/vm/oo/Class.c
index 3b11724..85fa5a3 100644
--- a/vm/oo/Class.c
+++ b/vm/oo/Class.c
@@ -4252,28 +4252,29 @@ noverify:
     if (clazz->refOffsets != CLASS_WALK_SUPER) {
         InstField *f;
         int i;
+        int cnt= clazz->ifieldRefCount;
 
         /* All of the fields that contain object references
          * are guaranteed to be at the beginning of the ifields list.
          */
-        f = clazz->ifields;
-        for (i = 0; i < clazz->ifieldRefCount; i++) {
-            /*
-             * Note that, per the comment on struct InstField,
-             * f->byteOffset is the offset from the beginning of
-             * obj, not the offset into obj->instanceData.
-             */
-            assert(f->byteOffset >= CLASS_SMALLEST_OFFSET);
-            assert((f->byteOffset & (CLASS_OFFSET_ALIGNMENT - 1)) == 0);
-            u4 newBit = CLASS_BIT_FROM_OFFSET(f->byteOffset);
-            if (newBit != 0) {
-                clazz->refOffsets |= newBit;
-            } else {
+ if(cnt>0) {
+#define CLASS_BIT_SHIFT_COUNT(byteOffset) (((unsigned int)(byteOffset) - CLASS_SMALLEST_OFFSET) /  CLASS_OFFSET_ALIGNMENT)
+            f = clazz->ifields;
+     if( CLASS_BIT_SHIFT_COUNT(f[cnt-1].byteOffset) >= CLASS_BITS_PER_WORD)
                 clazz->refOffsets = CLASS_WALK_SUPER;
-                break;
+     else for (i = 0; i < cnt; i++) {
+                /*
+                * Note that, per the comment on struct InstField,
+                * f->byteOffset is the offset from the beginning of
+                * obj, not the offset into obj->instanceData.
+                */
+                assert(f->byteOffset >= CLASS_SMALLEST_OFFSET);
+                assert((f->byteOffset & (CLASS_OFFSET_ALIGNMENT - 1)) == 0);
+                u4 newBit = CLASS_BIT_FROM_OFFSET(f->byteOffset);
+                clazz->refOffsets |= newBit;
+                f++;
             }
-            f++;
-        }
+ }
     }
 
     if (dvmCheckException(self)) {

[Barry Hayes]

I have submitted a new version of this code:
https://review.source.android.com/#change,10635

Please feel free to review and comment. Thanks all for your patience,
sorry about introducing a defect in the first place.

--
bhayes yat cs dot stanford dot edu is what you should put in your
contact files -- it'll forward to me no matter where I move

[profect]

I have two concerns for this problem.

 

1. I think what Chen mentioned above is also a problem. Gcc's implementation for ">>" is different from the code's intention here.

 

2. Does JVM specification allows an instance is created before finishing its class initialization?

 

Thanks.

[fadden]

On Jul 12, 7:46 pm, profect <profect.andr...@gmail.com> wrote:
> 1. I think what Chen mentioned above is also a problem. Gcc's implementation
> for ">>" is different from the code's intention here.

If you're signed up as a contributor, go to the change page, click on
the file, and double-click on the line you're concerned about. You
can enter your comments inline.

> 2. Does JVM specification allows an instance is created before finishing its
> class initialization?

Yes: you can create an instance of a class during the initialization
of that class.

You can't create one until after verification, however.

[DYChen]

> > 2. Does JVM specification allows an instance is created before finishing its
> > class initialization?
>
> Yes: you can create an instance of a class during the initialization
> of that class.
>
> You can't create one until after verification, however.

The description in Section 12.4.1 of
http://java.sun.com/docs/books/jls/second_edition/html/execution.doc.html
says:

"A class or interface type T will be initialized immediately before
the first occurrence of any one of the following:

* T is a class and an instance of T is created.
* T is a class and a static method declared by T is invoked.
* A static field declared by T is assigned.
* A static field declared by T is used and the reference to the field
is not a compile-time constant (§15.28). References to compile-time
constants must be resolved at compile time to a copy of the compile-
time constant value, so uses of such a field never cause
initialization. "

This seems to imply an instance can only be created after the class
initialization is completed.

[fadden]

On Jul 14, 12:39 am, DYChen <dong-yuan.c...@intel.com> wrote:
> This seems to imply an instance can only be created after the class
> initialization is completed.

It tells you the set of actions that trigger initialization. It does
not guarantee that initialization has completed before those actions
complete.

Consider this example:

public class Foo {
public static Foo mFoo;

static {
System.out.println("static init begin");
mFoo = new Foo();
System.out.println("static init end");
}

public static void main(String[] args) {
Foo foo = new Foo();
System.out.println("done" + mFoo);
}

public Foo() {
System.out.println("creating a foo!");
}
}

% javac Foo.java && java Foo
static init begin
creating a foo!
static init end
creating a foo!
doneFoo@4aad3ba4

The "new Foo" in main() causes class initialization of Foo. The class
initializer creates a new instance with "new Foo". The VM has to
choose between allowing the second allocation to complete while class
init is in progress, or throwing some sort of "not ready yet"
exception.

This isn't a problem unless the Foo constructor tries to use static
fields that haven't been initialized yet.