Return-Path: X-Original-To: apmail-openjpa-dev-archive@www.apache.org Delivered-To: apmail-openjpa-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id B10E2F3B9 for ; Wed, 10 Apr 2013 14:50:17 +0000 (UTC) Received: (qmail 9109 invoked by uid 500); 10 Apr 2013 14:50:17 -0000 Delivered-To: apmail-openjpa-dev-archive@openjpa.apache.org Received: (qmail 9065 invoked by uid 500); 10 Apr 2013 14:50:17 -0000 Mailing-List: contact dev-help@openjpa.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@openjpa.apache.org Delivered-To: mailing list dev@openjpa.apache.org Received: (qmail 9049 invoked by uid 99); 10 Apr 2013 14:50:17 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 10 Apr 2013 14:50:17 +0000 Date: Wed, 10 Apr 2013 14:50:17 +0000 (UTC) From: "Albert Lee (JIRA)" To: dev@openjpa.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Resolved] (OPENJPA-2298) VerifyError/Stack underflow due to extra 'return' statements generated by PCEnhancer. MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/OPENJPA-2298?page=3Dcom.atlass= ian.jira.plugin.system.issuetabpanels:all-tabpanel ] Albert Lee resolved OPENJPA-2298. --------------------------------- Resolution: Fixed =20 > VerifyError/Stack underflow due to extra 'return' statements generated by= PCEnhancer. > -------------------------------------------------------------------------= ------------ > > Key: OPENJPA-2298 > URL: https://issues.apache.org/jira/browse/OPENJPA-2298 > Project: OpenJPA > Issue Type: Bug > Components: Enhance, instrumentation > Affects Versions: 2.2.0, 2.3.0 > Reporter: Heath Thomann > Assignee: Heath Thomann > Priority: Critical > Fix For: 2.3.0, 2.2.2, 2.2.1.1 > > Attachments: PersistentTimerStatsJPA.java, PersistentTimerStatsPK= .java, VerifyError.patch > > > I've been assisting Kevin Sutter with a 'VerifyError' and am opening this= JIRA on his behalf. He has discovered a situation where the following Ver= ifyError occurs: > Exception data: java.lang.VerifyError: JVMVRFY036 stack underflow; class= =3Dirwwbase/PersistentTimerStatsJPA, method=3DpcNewObjectIdInstance(Ljava/l= ang/Object;)Ljava/lang/Object;, pc=3D26 > at java.lang.J9VMInternals.verifyImpl(Native Method) > at java.lang.J9VMInternals.verify(J9VMInternals.java:85) > at java.lang.J9VMInternals.initialize(J9VMInternals.java:162) > at java.lang.Class.forNameImpl(Native Method) > at java.lang.Class.forName(Class.java:176) > at org.apache.openjpa.meta.MetaDataRepository.classForName(MetaDataRe= pository.java:1552) > at org.apache.openjpa.meta.MetaDataRepository.loadPersistentTypesInte= rnal(MetaDataRepository.java:1528) > at org.apache.openjpa.meta.MetaDataRepository.loadPersistentTypes(Met= aDataRepository.java:1506) > at org.apache.openjpa.kernel.AbstractBrokerFactory.loadPersistentType= s(AbstractBrokerFactory.java:282) > at org.apache.openjpa.kernel.AbstractBrokerFactory.initializeBroker(A= bstractBrokerFactory.java:238) > at org.apache.openjpa.kernel.AbstractBrokerFactory.newBroker(Abstract= BrokerFactory.java:212) > at org.apache.openjpa.kernel.DelegatingBrokerFactory.newBroker(Delega= tingBrokerFactory.java:156) > at org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEnti= tyManager(EntityManagerFactoryImpl.java:227) > ........... > This issue occurs on, and is unique to, Java 7 and our enhancement code (= as well as the entity definition). That is, in PCEnhancer we are generatin= g extra 'returns' in methods which throw an exception. This has an effect = on ASM post-processing needed on Java 7 which ultimately causes the VerifyE= rror. This description probably makes no sense without more details and co= de to go along with it. So let me now show how this looks in code. First,= I'm attaching an entity, named PersistentTimerStatsJPA.java, and a PK clas= s named 'PersistentTimerStatsPK.java'. While I won't go into exact details= on how to use these classes to recreate the issue, I am providing them for= the reader's reference. > Next, lets look at enhanced code before ASM post-processing occurs. Take= this code: > =C2=A0 public java.lang.Object pcNewObjectIdInstance(java.lang.Object); > =C2=A0=C2=A0=C2=A0 flags: ACC_PUBLIC > =C2=A0=C2=A0=C2=A0 Code: > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 stack=3D3, locals=3D2, args_size=3D2 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 0: new=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 #207=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 // class ja= va/lang/IllegalArgumentException > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 3: dup=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=20 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 4: ldc_w=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 #367=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 // String The id typ= e \"class irwwbase.PersistentTimerStatsPK\" specified by persistent type \"= class irwwbase.PersistentTimerStatsJPA\" does not have a public class irwwb= ase.PersistentTimerStatsPK(String) or class irwwbase.PersistentTimerStatsPK= (Class, String) constructor. > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 7: invokespecial #368=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 // Method java/lang/IllegalArgumentException."":(Ljava/l= ang/String;)V > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 10: athrow=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=20 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 11: return=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=20 > As you can see, we have a "10: athrow" and "11: return". This extraneous= "11: return" hasn't caused problems in the past, but as will be explained = in more details below, with ASM post-processing necessary in Java 7, this "= 11: return" causes problems. To see this, lets look at the code above afte= r going through ASM post-processing: > =C2=A0 public java.lang.Object pcNewObjectIdInstance(java.lang.Object); > =C2=A0=C2=A0=C2=A0 flags: ACC_PUBLIC > =C2=A0=C2=A0=C2=A0 Code: > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 stack=3D3, locals=3D2, args_size=3D2 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 0: new=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 #205=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 // class ja= va/lang/IllegalArgumentException > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 3: dup=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=20 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 4: ldc_w=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 #363=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 // String The id typ= e \"class irwwbase.PersistentTimerStatsPK\" specified by persistent type \"= class irwwbase.PersistentTimerStatsJPA\" does not have a public class irwwb= ase.PersistentTimerStatsPK(String) or class irwwbase.PersistentTimerStatsPK= (Class, String) constructor. > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 7: invokespecial #364=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 // Method java/lang/IllegalArgumentException."":(Ljava/l= ang/String;)V > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 10: athrow=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=20 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 11: athrow=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=20 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 StackMapTable: number_of_entries =3D 1 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 frame_type = =3D 255 /* full_frame */ > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 offset_delta =3D 1= 1 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 locals =3D [] > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 stack =3D [ class = java/lang/Throwable ] > Notice that the "11: return" was changed to a second "11: athrow". To ti= e this all together, let me blatantly copy/paste a detailed description sen= t to me by Kevin:=20 > "When JPA was attempting to generate the bytecodes for throwing an except= ion, we were accidentally including a return bytecode as well. Of course, = in a normal Java environment, this would have been flagged since the return= would have been unreachable code. But, since we were generating the bytec= odes during enhancement, nothing is going to flag this situation. But, due= to the Java 7 class validation that is now being performed, we had to intr= oduce the ASM post-processing. Normally, these simple enhanced methods wou= ld not have been touched by ASM. But, since these methods now had multiple= exit points (due to the throw and return bytecodes), these methods were be= ing flagged as "complicated" and needed Stack Map table adjustments perform= ed by ASM. Unfortunately, this additional ASM code now introduced the situ= ation where too many items would have been popped off the stack (if the cod= e could have actually executed as coded). This is the Stack Underflow exce= ption that was happening during Class load time." > Basically, Kevin's fix was to find all of the areas where we generate a "= throw" followed by a "return", and remove the "return". Since this method = is only attempting to throw an exception, we really don't need the second "= return" instruction. I'm providing Kevin's patch, which is named 'VerifyEr= ror.patch'. > Thanks, > Heath -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrato= rs For more information on JIRA, see: http://www.atlassian.com/software/jira