You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@groovy.apache.org by "Winnebeck, Jason" <Ja...@windstream.com> on 2016/08/24 21:10:41 UTC

Line numbers and debugging in method when branching

Consider the following class:

class Debugging {
public static void main(String[] args) {
  a: if (args.length > 0) {
   b: println "args"
  }
}
}

And let's say that I run the program with no arguments, and I put IntelliJ debugger to break on line a. Now when I "step next" I see it highlight line b, then step next and the program ends. The line b clearly did not run. Is this a problem with IntelliJ or the bytecode? Below is the bytecode for the method. I'm assuming the issue is that L2 is before the return, and at the return bytecode we see before it LINENUMBER 4. If the return was annotated with a linenumber 5 or 6, I assume the debugger would step to the closing brace of the if statement (or of the method itself, depending on what was preferred). Is this an issue with the IntelliJ debugger, or is it really a limitation of the Groovy bytecode generation? A workaround is if I put an empty return statement at the end of main, the debugger works, but strangely in bytecode I see two returns.

  public static transient varargs main([Ljava/lang/String;)V
   L0
    INVOKESTATIC Debugging.$getCallSiteArray ()[Lorg/codehaus/groovy/runtime/callsite/CallSite;
    ASTORE 1
   L1
    LINENUMBER 3 L1
    ALOAD 1
    LDC 0
    AALOAD
    ALOAD 0
    INVOKEINTERFACE org/codehaus/groovy/runtime/callsite/CallSite.callGetProperty (Ljava/lang/Object;)Ljava/lang/Object;
    ICONST_0
    INVOKESTATIC java/lang/Integer.valueOf (I)Ljava/lang/Integer;
    INVOKESTATIC org/codehaus/groovy/runtime/ScriptBytecodeAdapter.compareGreaterThan (Ljava/lang/Object;Ljava/lang/Object;)Z
    IFEQ L2
   L3
    LINENUMBER 4 L3
    ALOAD 1
    LDC 1
    AALOAD
    LDC LDebugging;.class
    LDC "args"
    INVOKEINTERFACE org/codehaus/groovy/runtime/callsite/CallSite.callStatic (Ljava/lang/Class;Ljava/lang/Object;)Ljava/lang/Object;
    POP
   L2
    RETURN
    LOCALVARIABLE args [Ljava/lang/String; L0 L2 0
    MAXSTACK = 3
    MAXLOCALS = 2

Jason Winnebeck

This email message and any attachments are for the sole use of the intended recipient(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message and any attachments.

RE: Line numbers and debugging in method when branching

Posted by "Winnebeck, Jason" <Ja...@windstream.com>.
Thanks Jochen, I created https://issues.apache.org/jira/browse/GROOVY-7918 for this issue.

Jason

-----Original Message-----
From: Jochen Theodorou [mailto:blackdrag@gmx.org] 
Sent: Thursday, August 25, 2016 1:49 AM
To: users@groovy.apache.org
Subject: Re: Line numbers and debugging in method when branching

On 24.08.2016 23:10, Winnebeck, Jason wrote:
> Consider the following class:
>
> *class *Debugging {
> *public static void *main(String[] args) {
> *a*: *if *(args.*length *> 0) {
> *b*: println *"args"
> *}
> }
> }
>
> And let's say that I run the program with no arguments, and I put 
> IntelliJ debugger to break on line a. Now when I "step next" I see it 
> highlight line b, then step next and the program ends. The line b 
> clearly did not run. Is this a problem with IntelliJ or the bytecode?
> Below is the bytecode for the method. I'm assuming the issue is that 
> L2 is before the return, and at the return bytecode we see before it 
> LINENUMBER 4. If the return was annotated with a linenumber 5 or 6, I 
> assume the debugger would step to the closing brace of the if 
> statement (or of the method itself, depending on what was preferred). 
> Is this an issue with the IntelliJ debugger, or is it really a 
> limitation of the Groovy bytecode generation?

comparing with Java the last return should be annotated with the line with the closing brace of the method

> A workaround is if I put an empty return statement at the end of main, 
> the debugger works, but strangely in bytecode I see two returns.

that now is kind of a limitation of our bytecode generation

bye Jochen


This email message and any attachments are for the sole use of the intended recipient(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message and any attachments.

Re: Line numbers and debugging in method when branching

Posted by Jochen Theodorou <bl...@gmx.org>.
On 24.08.2016 23:10, Winnebeck, Jason wrote:
> Consider the following class:
>
> *class *Debugging {
> *public static void *main(String[] args) {
> *a*: *if *(args.*length *> 0) {
> *b*: println *"args"
> *}
> }
> }
>
> And lets say that I run the program with no arguments, and I put
> IntelliJ debugger to break on line a. Now when I step next I see it
> highlight line b, then step next and the program ends. The line b
> clearly did not run. Is this a problem with IntelliJ or the bytecode?
> Below is the bytecode for the method. Im assuming the issue is that L2
> is before the return, and at the return bytecode we see before it
> LINENUMBER 4. If the return was annotated with a linenumber 5 or 6, I
> assume the debugger would step to the closing brace of the if statement
> (or of the method itself, depending on what was preferred). Is this an
> issue with the IntelliJ debugger, or is it really a limitation of the
> Groovy bytecode generation?

comparing with Java the last return should be annotated with the line 
with the closing brace of the method

> A workaround is if I put an empty return
> statement at the end of main, the debugger works, but strangely in
> bytecode I see two returns.

that now is kind of a limitation of our bytecode generation

bye Jochen