Unfortunately, this doesn't seem to fully resolve my issue. I have
created a very simple repro case that causes the stall to occur (let
me know if anyone wants the source / APK). In the test, it will
eventually finish but it takes ~10 seconds just to make the call:
Class.forName("com.zoltu.AndroidTest.Messages.Sample")
On the plus side, the sample code isn't deadlocking, but it looks like
I'll still need to test on a physical device to see if it takes a
noticeable amount of time there like on the VM.
On Jul 22, 10:49 am, fadden <[email protected]> wrote:
> 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
> inhttp://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
-~----------~----~----~----~------~----~------~--~---
