RFR: 8339192: Native annotation parsing code of deprecated annotations causes crash [v2]

[Chen Liang]

On Tue, 17 Sep 2024 05:36:58 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> There are a couple of runtime visible annotations (`@Deprecated`, `@Contended`) that the VM processes during classfile parsing. These are expected to have a form that matches the corresponding Java source code in the JDK. The original test cases for this bug fuzzed the annotation entry in the classfile such that the correspondence was lost and so assertions and other errors could be triggered (depending on debug or release builds). The fix is to fully validate the annotation entries that appear to match, and to ignore them otherwise (which is what is required for unknown attributes/annotations).
>> 
>> Each of the jcod test cases is targeted at a specific change in the code (typically the removal of an assertion). There is no intent to try and write exhaustive tests for all possible malformities that might exist for an annotation entry. The original submitted test cases now run without error.
>> 
>> Testing was verified manually by adding debug printing to show we rejected each case as expected. Unfortunately there is no existing mechanism to read back the VM's view of what annotations are present, nor is there any logging to take advantage of. I briefly considered adding a WhiteBox API to query the annotations applied in the VM but I deemed it not worth the effort, particularly because it didn't really help validate the tests in many cases. For example, by default no class/method/field is "Deprecated for Removal" so a test that skips `forRemoval` setting just leaves you with the default situation. You can't actually tell a bad annotation was skipped.
>> 
>> Testing
>>  - new tests as described above 
>>  - tier 1-3 sanity
>> 
>> Thanks
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   MIN macro was Linux specific - need MIN2

Indeed, the specs only require us to correctly recognize completely correct format and silently ignore anything that's wrong. For a partially correct structure (including structurally valid but semantically invalid, such as duplicate members), any leniency should be fine.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21030#issuecomment-2357051365