groovy-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul King (JIRA)" <j...@apache.org>
Subject [jira] [Closed] (GROOVY-8742) Line number information for method is confusing debugger
Date Thu, 13 Dec 2018 10:03:00 GMT

     [ https://issues.apache.org/jira/browse/GROOVY-8742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Paul King closed GROOVY-8742.
-----------------------------

> 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
>            Assignee: Paul King
>            Priority: Major
>             Fix For: 2.4.16, 3.0.0-alpha-4, 2.5.5
>
>
> 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, with a chain of three method calls.
 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
>     Assert.assertFalse(this.method(one(), "two", Three.class)) // line 30
>   }
>   boolean method(... args) { true }
>   def one() {}
> }
> {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