[jboss-jira] [JBoss JIRA] Updated: (JASSIST-72) Instrumenting write access using CodeConverter.replaceArrayAccess(...) causes VerifyError (Unable to pop operand off an empty stack) - buggy aastore

[Martin Burger (JIRA)]

     [ https://jira.jboss.org/jira/browse/JASSIST-72?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Burger updated JASSIST-72:
---------------------------------

    Attachment: array_issue.tgz


The attached files contains additional data about this issue:

TokenStream.java

The original source code file. The corresponding class file is instrumented by
my tool.


Directories

Each of the following directories contains same (instrumented) class files
and data obtained while analyzing this issue:

TokenStream.jad                          - decompiled class file using 'jad -b -dead -ff -lnc -nonlb'
org.mozilla.javascript.TokenStream*.html - decompiled class file using 'org.apache.bcel.util.Class2HTML'
javassist.dump                           - output of javassist.tools.Dump
javassist.framedump                      - output of javassist.framedump
javap.dump                               - output of javap

I think the most useful data is contained in org.mozilla.javascript.TokenStream*.html.


1-array_issue-not_instrumented

This directory contains the unmodified class files.


2-array_issue-instrumented_including_arrays-not_working

Contains the classes with all instrumentations enabled, including array
accesses.

Here you can find the suspicious class "org.mozilla.javascript.TokenStream".
While loading this instrumented version, the Java verifier complained by
throwing a java.lang.VerifyError. Unfortunately, the method that caused this
error is quite long. Thus, the information "Unable to pop operand off an empty
stack" is not very helpful because we do not have the corresponding byte code
instruction.

I used javassist.tools.framedump to dump all the frames in this class. Again, an
exception was thrown. This time the error message contains the exact position:
7046.

See the README file in this directory for more information.


> Instrumenting write access using CodeConverter.replaceArrayAccess(...) causes VerifyError (Unable to pop operand off an empty stack) - buggy aastore
> ----------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JASSIST-72
>                 URL: https://jira.jboss.org/jira/browse/JASSIST-72
>             Project: Javassist
>          Issue Type: Bug
>         Environment: javassist 3.9.0.GA
>            Reporter: Martin Burger
>            Assignee: Shigeru Chiba
>         Attachments: array_issue.tgz
>
>
> I use Javassist to instrument class files in order to catch some runtime information. Basically, I insert probes to get information about method calls, field accesses, and so on. This includes access to arrays. Unfortunately, when I instrument array accesses using CodeConverter.replaceArrayAccess(...) the Java verifier throws an exception while loading the changed method: Unable to pop operand off an empty stack.
> Instrumenting array accesses is one instrumentation of many. If I disable instrumentation of array accesses, the instrumented program will run and I will get runtime information about method calls etc. As soon as I enable the instrumentation of arrays, the byte code created by javassist causes the java.lang.VerifyError mentioned above.
> The buggy byte code instruction seems to be:
>    7016:	anewarray	#51; //class java/lang/Object
>    7019:	dup
>    7020:	iconst_0
>    7021:	iload_1
>    7022:	bipush	56
>    7024:	if_icmpne	7036
>    7027:	ldc_w	#5369; //String 8
>    7030:	nop
>    7031:	nop
>    7032:	nop
>    7033:	goto	7042
>    7036:	ldc_w	#5371; //String 9
>    7039:	nop
>    7040:	nop
>    7041:	nop
>    7042:	invokestatic	#5373;
>    7045:	nop
>    7046:	aastore <-- causes VerifyError
> At least when executing aastore the stack is empty already.
> The original source code:
> if (base == 8 && c >= '8') {
>     Object[] errArgs = { c == '8' ? "8" : "9" };
>     reportCurrentLineWarning(
>         "msg.bad.octal.literal", errArgs);
>     base = 10;
> }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira