On Tuesday 08 August 2006 00:01 Geir Magnusson Jr wrote: > Ok - I made that fix and still seem to have a problem, even after a > clean rebuild. I guess I should figure out how to turn on the trace...
The problem is that class loader does not chain VerifyError to NoClassDefFoundError so debugging such problems is diffucult without tracing. I think this is a place for improvement in drlvm. I tried to fix the problem and found out that verifier just doesn't understand exception handlers which point to the code length address (code end + 1). It is a surprise that this problem didn't appear earlier. My patch attached to JIRA attempts to fix the problem in verifier only, the application still fails to start. In default mode it exits silently, I didn't find any exception logs or something. When using interpreter -Xint it fails with ArrayStoreException still without any stack trace. I'll try to find out what is happening. > Anton Luht wrote: > > Hello, > > > > The problem is with verifier. > > > > The code in Verifier.cpp: > > > > if( ( start_pc >= len ) || ( end_pc >= len ) || ( handler_pc >= > > len ) ) > > ... > > > > result = VER_ErrorHandler; > > > > I've modified error logging a bit to log values of start_pc, end_pc, > > handler_pc and len and that's the output: > > > > > > Loading message broker from: xbean:activemq.xml > > vf_debug: VerifyError: (class: > > edu/emory/mathcs/backport/java/util/concurrent/lo > > cks/ReentrantLock$NonfairSync, method: lockInterruptibly()V, len: 103, > > start_pc: > > 87, end_pc: 103, handler_pc: 21) Handler pc is out of range > > vf_debug: verifying class > > edu/emory/mathcs/backport/java/util/concurrent/locks/R > > eentrantLock (method <init>()V) couldn't load class > > "edu/emory/mathcs/backport/j > > ava/util/concurrent/locks/ReentrantLock$NonfairSync" > > vf_debug: VerifyError: > > edu/emory/mathcs/backport/java/util/concurrent/locks/Reen > > trantLock$NonfairSync > > Failed to execute main task. Reason: java.lang.NoClassDefFoundError: > > edu/emory/m > > athcs/backport/java/util/concurrent/locks/ReentrantLock$NonfairSync > > > > I'm not an expert in verification but seems like > > > > end_pc >= len > > should be replaced with > > end_pc > len > > > > On 8/5/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: > >> Anyone interested? :) -- Gregory Shimansky, Intel Middleware Products Division --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
