Thanks for the insights. I broke up the method into several smaller ones, and now it works !
... at least until it's time to regenerate the class (the class is automatically generated by ANTLR, a parser generator). On 29 Sep., 23:15, DanH <[email protected]> wrote: > Java has some fairly arbitrary restrictions on the size of programs. > Most are fairly reasonable, but one that isn't so much is the one that > limits the number of bytecodes in a method to 65535. (Curiously, > <clinit> methods can have more.) > > In general, a verifier should be able to handle any large method up to > the 65535 limit without choking, but there are a number of oddball > (and not so oddball) cases where Sun's can't, and most other verifiers > have similar Achilles heels. (Eg, I wrote the "BigUglyMethod" > testcase that breaks Sun's verifier, even though it's only a few > hundred lines long.) (And rather than respond by fixing the verifier, > Sun did a major redesign of the bytecode file format to circumvent the > problem. Though curiously they never did the very minor modifications > that would have been required to lift the 65535 limitation.) > > Anyway, it's likely that this program is bumping into several limits > in the Dalvik. The best thing to do would be to figure out some way > to break up the mongo method that's causing these problems. > > On Sep 29, 1:32 pm, Dirk <[email protected]> wrote: > > > Just for the sake of completeness: > > In order to get around the problem, I tried to replace the whole > > switch-statement with lots of if-elseif statements. > > Unfortunately, another problem arose. The Verifyer now says: > > > 09-29 18:02:44.058: WARN/dalvikvm(450): VFY: arbitrarily rejecting > > large method (regs=127 count=34916) > > > There's already another thread on this > > topic:http://groups.google.com/group/android-developers/browse_thread/threa... > > > Maybe one should keep this issue in mind when fixing the Verifier bug, > > cause they seem to go hand in hand. > > > Cheers Dirk > > > The method has several thousand lines ( ~ 3000 to 9000 lines, > > depending on the formatting) of code > > On 28 Sep., 22:53, fadden <[email protected]> wrote: > > > > On Sep 28, 11:28 am, Dirk <[email protected]> wrote: > > > > > Before filing a bug, I would feel much better if someone else could > > > > have a look and approve that there's really something not working as > > > > it should. > > > > It's a bug in the verifier. Specifically, dvmCheckSwitchTargets is > > > treating the switch table offset as a 16-bit value when it's actually > > > a 32-bit value. The switch statement data starts at 0x00008664. -- 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
