On Mar 1, 10:27 pm, dhananjay <dhananjayingr...@gmail.com> wrote:
> V/dalvikvm( 368): +++ dvmAddClassToHash 'Ljava/lang/ClassLoader;
> V/dalvikvm( 368): THROW 'Ljava/lang/VerifyError;'
> msg='java.lang.Class' cause=(none)
> V/dalvikvm( 368): +++ dvmAddClassToHash 'Ljava/lang/VerifyError;' 0x0
> (isnew=1) --> 0x2aab0dd0
> V/dalvikvm( 368): +++ dvmAddClassToHash 'Ljava/lang/LinkageError;
> V/dalvikvm( 368): +++ dvmAddClassToHash 'Ljava/lang/Error;
> V/dalvikvm( 368): THROW 'Ljava/lang/VerifyError;'
> msg='Ljava.lang.Error;' cause=(none)
> E/dalvikvm( 368): Too many exceptions during init (failed on 'Ljava/
> lang/VerifyError;' 'Ljava.lang.Error;')
Looks like it's encountering some sort of verification error in
java.lang.Class. This is a pretty fundamental piece, so when the
errors start to cascade the VM realizes that it's hosed and just
aborts.
Generally when the verifier encounters a problem it logs a bunch of
stuff before it throws a VerifyError, but those are largely suppressed
while dexopt runs. In dalvik/vm/analysis/VerifySubs.c there's a
function called dvmLogVerifyFailure that does this:
if (gDvm.optimizing) {
return;
//logLevel = ANDROID_LOG_DEBUG;
} else {
logLevel = ANDROID_LOG_WARN;
}
Replace the "return" with the commented-out line and try again.
That should let you see what it's complaining about. Making it happy
is the next step. :-)
--
unsubscribe: android-porting+unsubscr...@googlegroups.com
website: http://groups.google.com/group/android-porting
