Local variables debug info unavailable

Hi all,

Why "Local variables debug info unavailable" if I try to step into and debug e.g. java.lang.String?

JDK sources are in Sourcepath.


Thank you.

9 comments
Comment actions Permalink

Andrei wrote:

Hi all,

Why "Local variables debug info unavailable" if I try to step into and debug e.g. java.lang.String?

JDK sources are in Sourcepath.


Thank you.


I think it's because the JDK classes were not compiled with debug info,
probably for performance or classfile size.

0
Comment actions Permalink

Keith, that's true, but it's also kind of a lame excuse.

While other debuggers can extract the needed information from source code, Idea is just too dumb to do so:

http://www.jetbrains.net/jira/browse/IDEABKL-1490

0
Comment actions Permalink

Stephen Kelvin wrote:

Keith, that's true, but it's also kind of a lame excuse.

While other debuggers can extract the needed information from source code, Idea is just too dumb to do so:

http://www.jetbrains.net/jira/browse/IDEABKL-1490


I don't know if I think JB should spend their time implementing that
feature. It's a more natural feature for CodeGuide because they use
their own proprietary compiler, so they can compile a method on the fly
to see what its locals would look like. However, it seems that this
would be a huge project in IDEA, because it has no such compiler.

0
Comment actions Permalink

I think you exaggerate the problem a lot.
IMHO all that is needed is a mapping of local variable index (as stored in the byte code) to and from variable name.
That can very easily be extracted from the parse tree which is already available in Idea (PSI structure).
But maybe I am missing something?

0
Comment actions Permalink

Stephen Kelvin wrote:

I think you exaggerate the problem a lot.
IMHO all that is needed is a mapping of local variable index (as stored in the byte code) to and from variable name.
That can very easily be extracted from the parse tree which is already available in Idea (PSI structure).
But maybe I am missing something?


I haven't worked with bytecode directly, but in the intermediate format
of the Soot compiler, lots of locals are created for things you don't
ever see in code (like intermediate results of nested expressions,
references to this, references to fields generated when you use
anonymous and local classes).

It would probably not require full compilation of the method to
determine which locals correspond to which variables in the code, but I
think it would be close.

0
Comment actions Permalink

This is kind of interesting.
For parameters the simple approach definitly would work.
See Java Virtual Machine Specification:

3.6.1 Local Variables
The Java virtual machine uses local variables to pass parameters on method invocation. On class method invocation any parameters are passed in consecutive local variables starting from local variable 0. On instance method invocation, local variable 0 is always used to pass a reference to the object on which the instance method is being invoked (this in the Java programming language). Any parameters are subsequently passed in consecutive local variables starting from local variable 1.

I think intermediate results are only on the stack, not in the local variable table, but that's really just an assumption. One would have to dig deeper.

Still, even if omnicode has a custom compiler, it does not compile the JDK itself. It runs on any JDK you supply.
So it must be possible top infer local variables without re-compiling the byte code.

0
Comment actions Permalink

Stephen Kelvin wrote:

Still, even if omnicode has a custom compiler, it does not compile
the JDK itself. It runs on any JDK you supply. So it must be possible
top infer local variables without re-compiling the byte code.


I guess that CodeGuide semi-compiles the method you're currently
stepping in, on the fly, then uses the locals it generated to guess what
locals are in the actual JDK bytecode.

0
Comment actions Permalink

Should it not be possible to solve this problem by recompiling JDK classes (with debug info included) and including the recompiled jar into the project as a library?

I tried that with Swing classes, but to no avail. I made sure to place my library first (before JDK libraries). Am I missing something?

Thanks in advance for any ideas!
Tony

0
Comment actions Permalink


Tony wrote:

Should it not be possible to solve this problem by recompiling JDK classes (with debug info included) and including the recompiled jar into the project as a library?

I tried that with Swing classes, but to no avail. I made sure to place my library first (before JDK libraries). Am I missing something?

Yes. Let's say you have compiled Swing into swing-debug.jar. What you
need it to tell the VM that your jar is the main runtime one, not the
one in the Java installation direcotry. To do so, add the following
virtual machine parameter to the Run configuration:

-Xbootclasspath:/path/to/swing-debug.jar

That way the VM will first load the classes from you swing-debug.jar and
that way will skip the original swing classes.

It worked for me, I hope it will work for you also.

Greetings!

Thanks in advance for any ideas!
Tony

0

Please sign in to leave a comment.