Ah, I've now run into this issue also, it seems. Strangely, it works just fine for the most part, except for random, unreproducable cases, where it starts to hang somewhere inside getDeclaredMethods().
> easiest way to do this is to call Class.forName(String className) > early in the app start sequence. Does this mean Application.onCreate()? Michael fadden schrieb: > 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 -~----------~----~----~----~------~----~------~--~---
