[
https://issues.apache.org/jira/browse/MYFACES-2930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leonardo Uribe updated MYFACES-2930:
------------------------------------
Resolution: Fixed
Fix Version/s: 2.0.3-SNAPSHOT
Assignee: Leonardo Uribe
Status: Resolved (was: Patch Available)
Thanks to Christian Kaltepoth for provide this patch
> 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
> Assignee: Leonardo Uribe
> Priority: Minor
> Fix For: 2.0.3-SNAPSHOT
>
> 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.
