[External] : StackMap problem

[Chen Liang]

Hi Mark,
This indeed is weird - the ClassFile API's generation should force another branching check at bci 6 against the handler at 36 for frame compatibility, and should fail there. Unfortunately, I am busy with other projects right now and cannot divest a lot of time investigating this; can you try creating a minimal reproduction, like a simple method that has a try-catch and a post action, and a very simple transform, both of which don't require extra library dependencies?

Regards, Chen
________________________________
From: Mark Roberts <markro at cs.washington.edu>
Sent: Tuesday, January 28, 2025 2:45 PM
To: classfile-api-dev at openjdk.org <classfile-api-dev at openjdk.org>
Cc: Chen Liang <chen.l.liang at oracle.com>
Subject: [External] : StackMap problem


The existence of compiler generated, unnamed local temps (no LocalVariable code element) seems to cause a problem with stack maps.



The ‘source’ attachment shows the problem method.   The ‘before’ attachment shows the generated code before instrumentation.  Note that the compiler generates an unnamed temp at slot 0 to store the exception code. The stackmap for the branch target says same locals, which is correct.



The ‘after’ attachment shows the code generated after our tool has added instrumentation code – note the addition of a new local variable at slot 1.  The stackmap for the branch target still says same locals, which is no longer correct. This causes the iload_1 @41 to fail.



I tried to see if this issue has already been reported, but I was unable to figure out how to search https://bugs.java.com/bugdatabase/<https://urldefense.com/v3/__https://bugs.java.com/bugdatabase/__;!!ACWV5N9M2RV99hQ!J8Z_mD-T0Ps_kClOITgamtTMlXOdh7853QyTHD_sdbzUyIjKujz-4jcUs9Y0Y7iKjgO6vAwjbQvGbgT91qY0mw519Q$> by keyword.



Mark






-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/classfile-api-dev/attachments/20250128/d2c84040/attachment-0001.htm>