[jboss-jira] [JBoss JIRA] (JASSIST-210) MethodCall.replace() throws inconsistent stack height in certain scenarios

[Patson Luk (JIRA)]

    [ https://issues.jboss.org/browse/JASSIST-210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12934579#comment-12934579 ] 

Patson Luk edited comment on JASSIST-210 at 4/28/14 1:04 PM:
-------------------------------------------------------------

Many thanks for the detailed reply!

Since the JVM pops everything off the operation stack, looks like either we would have to track whatever is the operand stack (such that we can restore at the end of the catch block before the goto instruction) which is extremely complicated (don't know if it's even feasible)

or

refactor the code and take the target method invocation out if it's a part of another method's invocation, such that

ref.testMethod1(ref.testMethod2()); becomes

Ref tempVar = ref.testMethod2();
ref.testMethod(tempVar)

then I can add the try catch statement before or after the testMethod2 invocation statement (but not wrapping it).

I will try the latter. Thanks!
                
      was (Author: pluk):
    Many thanks for the detailed reply!

There is still one piece that I do not quite understand, would you please kindly elaborate?

You mentioned that after the translation 2 and 3 are replaced with a try-catch statement, but in the sample code, the replacement block $_ = $proceed($$) itself is NOT surrounded by try-catch, only the injected System.out... was surrounded by try-catch:

 "{ try
{ System.out.println(\"injected\"); }

catch (Exception e)
{ e.printStackTrace(); }

$_ = $proceed($$); }";

Therefore, if $_ = $proceed($$) does throw exception, it should still follow the same flow as if there is no try-catch? (as that piece of the code is not really wrapped)

Many thanks for your clarification in advanced
                  
> MethodCall.replace() throws inconsistent stack height in certain scenarios
> --------------------------------------------------------------------------
>
>                 Key: JASSIST-210
>                 URL: https://issues.jboss.org/browse/JASSIST-210
>             Project: Javassist
>          Issue Type: Bug
>    Affects Versions: 3.16.1-GA, 3.18.1-GA
>            Reporter: Patson Luk
>            Assignee: Shigeru Chiba
>
> Tested on 3.16.1-GA
> This is similar to https://issues.jboss.org/browse/JASSIST-52, but the try-catch block usage is different (not wrapping the $proceed($$))
> Based on the javassist tutorial,  the substituted code for MethodCall.replace():
> {{Note that the substituted code is not an expression but a statement or a block. It cannot be or contain a try-catch statement.}}
> However in the case that try-catch does not wrap the $_=$proceed($$);
> It seems to work properly. For example:
> ctClass.instrument(new ExprEditor() {
>     public void edit(MethodCall m) throws CannotCompileException {
>         if (m.getMethodName().equals("testMethod2")) {
>             String newBlock = "{ try { System.out.println(\"injected\"); } catch (Exception e) { e.printStackTrace(); } $_ = $proceed($$); }";
>             m.replace(newBlock);
>         }
>     }
> });
> {{which ctClass is class TestReplace, which has code as below:}}
> public class TestReplace {
>     public static void main(String[] args) {
>         RefClass ref = new RefClass();
>         ref.testMethod2();
>     }
> }
> class RefClass {
>     public void testMethod1(Object o) {}
>     public Object testMethod2() { return null; }
> }
> {{running TestReplace with the modified bytecode correctly prints "injected" to the screen. However if I add one more line to the TestReplace's main() method}}
> ref.testMethod1(ref.testMethod2());
> {{It throws exception as below}}
> javassist.bytecode.BadBytecode: inconsistent stack height -1
> javassist.bytecode.stackmap.Tracer.doOpcode(Tracer.java:106)
> *So is try-catch acceptable if it does not wrap the $_=$proceed($$)? If so, is it a bug if it does not work properly for method invocation within another method invocation?*
> Many thanks in advance!

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira