On Jul 21, 10:56 pm, fadden <[email protected]> wrote:
> The bug is that, while generating the list of declared methods, the VM
> would initialize classes found in method arguments.  Those classes
> shouldn't be getting initialized at that point, and initialization
> ordering problems ensue.

I got a copy of the APK (thanks!) and poked at it.  I believe this is
the same bug.

When the app launch stalled a sent the process a "kill -3" and pulled
the stack trace out of /data/anr/traces.txt.  The two interesting
threads are:

"main" prio=5 tid=3 WAIT
  | group="main" sCount=1 dsCount=0 s=N obj=0x4001d520 self=0xbc60
  | sysTid=1086 nice=0 sched=0/0 handle=-1343996920
  at java.lang.Class.getDeclaredMethods(Native Method)
  - waiting on <0x1a8598> (a java.lang.Class)
  at java.lang.ClassCache.getDeclaredPublicMethods(ClassCache.java:
166)
  at java.lang.ClassCache.getDeclaredMethods(ClassCache.java:179)
  at java.lang.ClassCache.findAllMethods(ClassCache.java:249)
  at java.lang.ClassCache.getFullListOfMethods(ClassCache.java:223)
  at java.lang.ClassCache.getAllPublicMethods(ClassCache.java:204)
  at java.lang.Class.getMethod(Class.java:1006)
  at com.google.protobuf.GeneratedMessage.getMethodOrDie
(GeneratedMessage.java:900)
  ...

"Graphics" prio=5 tid=19 WAIT
  | group="main" sCount=1 dsCount=0 s=N obj=0x43748ef8 self=0x1a4878
  | sysTid=1094 nice=0 sched=0/0 handle=1722776
  at com.ZZZ.Level$Map.<clinit>(Level.java:~1978)
  - waiting on <0x146768> (a java.lang.Class)
  at com.ZZZ.Level$LoadedAnnouncement.<init>(Level.java:-1)
  at com.ZZZ.Level$LoadedAnnouncement.<clinit>(Level.java:2586)
  at java.lang.Class.getDeclaredMethods(Native Method)
  at java.lang.ClassCache.getDeclaredPublicMethods(ClassCache.java:
166)
  ...

The're both under getDeclaredMethods, and they're both waiting on a
Class object monitor (but not the same class).  The Graphics thread is
doing a couple layers of class initialization that it shouldn't be
doing at that point.  It's possible we've deadlocked on class init.

I tried it twice and ended up in the exact same place both times.
With the bug fix in place it started up every time.

This problem will go away in a future release, but for now you can
work around it by forcing initialization to happen earlier.  The
easiest way to do this is to call Class.forName(String className)
early in the app start sequence.  Start with Level$Map and Level
$LoadedAnnouncement and see if that cures it.

For anyone building their own VM, you can see the patch in
http://code.google.com/p/android/issues/detail?id=3005 .

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to