groovy-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Milles (JIRA)" <j...@apache.org>
Subject [jira] [Created] (GROOVY-8742) Line number information for method is confusing debugger
Date Fri, 10 Aug 2018 18:43:00 GMT
Eric Milles created GROOVY-8742:
-----------------------------------

             Summary: Line number information for method is confusing debugger
                 Key: GROOVY-8742
                 URL: https://issues.apache.org/jira/browse/GROOVY-8742
             Project: Groovy
          Issue Type: Bug
          Components: bytecode, class generator
    Affects Versions: 2.4.15
            Reporter: Eric Milles


I have been investigating a case where the IDE will not break on a line breakpoint in a test
method.  This method has no parameters or local variables (this affects its line number table
in the bytecode) and the code is all on one line.  When line-breaking the code or assigning
to temporary, the line numbers table changes and the line breakpoints work as expected.

{code:groovy}
package a
import org.junit.*
final class Tests {
  @Test
  void testSomething() { // line 29
    assertSomething(instance.method(one, "two", Three.class)) // line 30
  }
}
{code}

When compiled with Groovy 2.4 and normal/dynamic groovy, the method has line information:
{code}
      Line numbers:
        [pc: 4, line: 29]
        [pc: 19, line: 30]
        [pc: 68, line: 30]
      Local variable table:
        [pc: 0, pc: 109] local: this index: 0 type: a.Tests
{code}

I have not tried with the "fast path" optimization disabled.  I think its prelude is what
bumps the PC from 0 to 4 and results in the two PC entries for line 30 (pc 19 and pc 68).

If I assign the result of {{method}} to a new local variable, the line numbers are altered:
{code}
      Line numbers:
        [pc: 6, line: 30]
        [pc: 63, line: 30]
        [pc: 100, line: 31]
      Local variable table:
        [pc: 0, pc: 113] local: this index: 0 type: a.Tests
        [pc: 6, pc: 113] local: variable index: 2 type: java.lang.Object
{code}

If I compile with invoke dynamic on, I get this for the original code:
{code}
      Line numbers:
        [pc: 0, line: 30]
      Local variable table:
        [pc: 0, pc: 30] local: this index: 0 type: a.Tests
{code}

I'm not sure the exact outcome expected here in terms of the bytecode, but I looked at similar
methods from Java sources.  For a Java test method, the line number table began with {{[pc:
0, line: whatever]}}.

I looked at GROOVY-4505, which mentions that {{AsmClassGenerator.visitBlockStatement}} should
not be writing line number information for the block statement (the source of line 29).  {{StatementWriter.writeBlockStatement}}
indeed retains a note about this.  However, the overload in {{OptimizingStatementWriter}}
still triggers `onLineNumber` from its `writeBlockStatement` -> {{writeGuards}}.  Should
{{onLineNumber}} check for {{BlockStatement}} and exit early?  I tried this quickly and it
did alter the line numbers table, but it did not help my debugger find the breakpoint on line
30.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Mime
View raw message