groovy-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jochen Theodorou (JIRA)" <>
Subject [jira] [Commented] (GROOVY-8289) STC and default value in ctor is causing debugging error
Date Tue, 15 Aug 2017 18:47:00 GMT


Jochen Theodorou commented on GROOVY-8289:

Maybe I can be of some help here

if you do {code:Java}
         0: aload_0
         1: invokespecial #20                 // Method java/lang/Object."<init>":()V
         4: aload_0
In the constructor, then the first aload 0 will load the uninitialized class. Only after we
have done the invokespecial, we have a full object on which we can actually call methods on.
In the example code here offset 4 is the first place with a valid this in the java sense.
In this normal constructor the LocalVariableTable shows the variable "this" starting at 4.

      stack=2, locals=1, args_size=1
         0: aload_0
         1: aconst_null
         2: invokespecial #33                 // Method "<init>":(Ljava/lang/String;)V
         5: return
we again load the unitialized class in 0 to then make the only valid method call with it,
which is a invokespecial to delegate object creation. so starting with 5 we have a valid "this"
in the Java sense here. LocalVariableTable though shows "this" starting at 0. So I guess it
really should start at 5. That would mean, if you step through with a debugger we may see
before 5 no local variables then. 

I guess that is what is requested to avoid the debugging error.

Do you share that view?

> STC and default value in ctor is causing debugging error
> --------------------------------------------------------
>                 Key: GROOVY-8289
>                 URL:
>             Project: Groovy
>          Issue Type: Bug
>          Components: bytecode
>    Affects Versions: 2.4.12
>            Reporter: Eric Milles
>         Attachments: C1.txt, C2.txt
> When debugging in the IDE, there is a curious behavior where it looks like step requests
are not being respected.  One thing I have found is that JDWP requests to the JVM process
are failing to resolve the variable "this" in certain cases.  I need some help from someone
who knows the bytecode better than myself to figure out where the problem lies.
> Original issue:
> I have narrowed it down to a small bit of code with static compilation enabled.
> {code}
> @groovy.transform.CompileStatic
> class C {
>   String string
>   C(String s = null) { string = s }
>   static void main(args) {
>     def c = new C('') // put breakpoint on this line, run as Java app, and step
>     println c
>   }
> }
> {code}
> Debug stepping fails when executing the constructor for C.  If I use {{new C(string:'')}},
the generated default constructor is used instead and debugging works fine.  So I think it
has something to do with the one-arg constructor's bytecode.
> I dumped the class file using javap and have attached them.  {{C1.txt}} is for the code
above.  {{C2.txt}} is the above with the named args constructor used instead.  I'm not sure
if the local args table for the single-argument constructor is bad and that is why "this"
cannot be resolved.
> There are several similar bugs reported for other tools and whatnots when looking for
"JDWP error code 35".  Hopefully, these help point to something in the bytecode that can be

This message was sent by Atlassian JIRA

View raw message