myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christian Kaltepoth (JIRA)" <...@myfaces.apache.org>
Subject [jira] Updated: (MYFACES-2930) ClassByteCodeAnnotationFilter doesn't read the constants pool correctly
Date Mon, 27 Sep 2010 06:14:33 GMT

     [ 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.


Mime
View raw message