[jira] Updated: (MYFACES-2930) ClassByteCodeAnnotationFilter doesn't read the constants pool correctly

["Christian Kaltepoth (JIRA)" <de...@myfaces.apache.org>]

     [ https://issues.apache.org/jira/browse/MYFACES-2930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Christian Kaltepoth updated MYFACES-2930:
-----------------------------------------

    Status: Patch Available  (was: Open)

> ClassByteCodeAnnotationFilter doesn't read the constants pool correctly
> -----------------------------------------------------------------------
>
>                 Key: MYFACES-2930
>                 URL: https://issues.apache.org/jira/browse/MYFACES-2930
>             Project: MyFaces Core
>          Issue Type: Bug
>          Components: General
>    Affects Versions: 2.0.3-SNAPSHOT
>            Reporter: Christian Kaltepoth
>            Priority: Minor
>         Attachments: MYFACES-2930.patch
>
>
> The ClassByteCodeAnnotationFilter used to check classes for annotations by reading their bytecode doesn't read the constants pool table correctly.
> The current code reads the number of entries from the class file and then reads each entry in the pool in a "for" loop. Unfortunately the code fails to process entries of the type "CONSTANT_Long" and "CONSTANT_Double" correctly. The Java VM spec says:
> "All 8-byte constants take up two entries in the constant_pool table of the class file. If a CONSTANT_Long_info or CONSTANT_Double_info structure is the item in the constant_pool table at index n, then the next usable item in the pool is located at index n+2. The constant_pool index n+1 must be valid but is considered unusable."
> From: http://java.sun.com/docs/books/jvms/second_edition/html/ClassFile.doc.html#1348
> The ClassByteCodeAnnotationFilter doesn't increase the loop counter for these entry types. Thus the filter will read bytes outside of the constants pool as soon as it finds a double or long constant in the constants pool because it will try to read more entries than there actually are.
> Please note that this doesn't lead to faulty behavior of the class, because if the reader reaches the end of the constants pool, it didn't find any reference until then and therefore it is OK to abort scanning and return "false".
> Find attached a patch containing a fix for this issue and a small unit test for the ClassByteCodeAnnotationFilter. I also added a log statement to default block of the switch statement. I guess this wasn't done because the current implementation often found bad tag values because of this bug. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.