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
