[ 
https://issues.apache.org/jira/browse/GROOVY-4063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16674555#comment-16674555
 ] 

Eric Milles commented on GROOVY-4063:
-------------------------------------

GROOVY-8472 seems related.  Line number information in class file is the reason 
the breakpoint does not hit.  When compiling without "indy", there is a 
fast-path conditional added and this generates two paths through the code and 
both receive line number information for the visible source.  This confuses the 
debugger.

> Debugger Step Into doesn't work in Groovy-compiled classes when stepping 
> filters are applied
> --------------------------------------------------------------------------------------------
>
>                 Key: GROOVY-4063
>                 URL: https://issues.apache.org/jira/browse/GROOVY-4063
>             Project: Groovy
>          Issue Type: Bug
>          Components: class generator
>    Affects Versions: 1.6.7, 1.7.0
>            Reporter: Peter Gromov
>            Priority: Major
>         Attachments: debug-test.tar.gz
>
>
> Reproduced in IntelliJ IDEA 9, GroovyEclipse 2.0 and JSWAT 4.5, therefore the 
> problem is probably in Groovy itself.
> Stepping class exclusion filters are set to ignore everything from Java and 
> Groovy internals: groovy.*,org.codehaus.groovy.*,java.*,sun.*,org.apache.*
> {code}
> class Some {
>       static void meth() {
>               println "Method is called."
>       }
>       public static void main(String[] args) {
>               meth()          // breakpoint here
>       }
> }
> {code}
> Run to the breakpoint in 'main' method. 'Step into'. There's a very long 
> pause (presumably JVM applies the filters to all the underlying groovy 
> internals), the message is printed and the program exits. Breakpoint is not 
> hit.
> Now put the breakpoint to the 'println' line in 'meth' and repeat stepping 
> into. This time the debugger stops at it.
> Stepping worked in earlier Groovy versions (e.g. 1.5) and stopped in 1.6. 
> Therefore I suspect it to be somehow mystically related to class generation 
> (or the libraries used, whatever)



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

Reply via email to