[ 
https://issues.apache.org/jira/browse/BCEL-79?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14305928#comment-14305928
 ] 

Mark Roberts commented on BCEL-79:
----------------------------------

This bug fix is quite incorrect and I have no idea how it how it solved the 
original bug.  The key point is there is absolutely no requirement for there to 
be as many LocalVariableTypeTable entries as there are LocalVariables.  In 
fact, there will almost always be fewer.  Quoting from the JVM spec, section 
4.7.14 "The LocalVariableTypeTable attribute differs from the 
LocalVariableTable attribute (ยง4.7.13) in that it provides signature 
information rather than descriptor information. This difference is only 
significant for variables whose type uses a type variable or parameterized 
type. Such variables will appear in both tables, while variables of other types 
will appear only in LocalVariableTable."
Thus deleting all the local variables and then reconstructing them from types 
is completely incorrect.  I have no idea what the bug fix intentions were -  
Perhaps the test case had the same number of vars and types??  Our fix was to 
simply comment the entire fix out and we have not run into any problems since.  
 (As an aside, it appears to be quite a flaw in BCEL verification test suite 
not to have caught this.)


> java.lang.ClassFormatError: LVTT entry for 'local' in class file 
> org/shiftone/jrat/test/dummy/CrashTestDummy does not match any LVT entry
> -----------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: BCEL-79
>                 URL: https://issues.apache.org/jira/browse/BCEL-79
>             Project: Commons BCEL
>          Issue Type: Bug
>          Components: Main
>            Reporter: Jeff Drost
>            Assignee: Apache Commons Developers
>            Priority: Blocker
>             Fix For: 6.0
>
>         Attachments: bcel-patch-method.txt
>
>
> I have tried both the release at http://people.apache.org/~tcurdt/bcel/rc2/ , 
> as
> well as a build from head (410655).  I see the same ClassFormatError with 
> both.
> I get this error when running a JRat test case.  This project and the test 
> case
> is avalible on sourceforge (http://sourceforge.net/projects/jrat) - or I can
> provide it directly.  The test case uses BCEL to isntrument a class and then
> tries to execute methods various methods on it.
> see org.shiftone.jrat.test.InjectorTestCase
> java.lang.ClassFormatError: LVTT entry for 'local' in class file
> org/shiftone/jrat/test/dummy/CrashTestDummy does not match any LVT entry
>       at java.lang.ClassLoader.defineClass1(Native Method)
>       at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
>       at java.lang.ClassLoader.defineClass(ClassLoader.java:465)
>       at 
> org.shiftone.jrat.test.TestClassLoader.loadClass(TestClassLoader.java:36)
>       at 
> org.shiftone.jrat.test.InjectorTestCase.setUp(InjectorTestCase.java:52)
>       at 
> com.intellij.rt.execution.junit2.JUnitStarter.main(JUnitStarter.java:32)
>       at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>       at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>       at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>       at com.intellij.rt.execution.application.AppMain.main(AppMain.java:90)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to