IntelliJ "Debug information unavailable"

Hi all,

I'm trying to debug some code, and I enter classes like java.net.URL etc... but when I want to debug a variable there, IntelliJ says: "Debug info unavailable".

So, my question is: How can I make it available? Do I need to enable some options? Turn classic VM off? Something else??

Thanks,

Erik

14 comments

Sadly the JDK classes have debug information for parameters and local variable stripped off.

Years ago I filed a request that Idea should deduce the necessary information from the source code (basically converting variable names to indexes into the methods local var):
Debugger: Show variable information when no debug info

Please vote/comment.

As a workaround you can re-compile the JDK from sources, but you need to exclude some classes which do not have all needed source code attached.

I am not sure if latest Java 7 early access builds have full debug information.

0

Stephen, thanks for the reply. I voted for this issue! It's sad that this is happening, cause I need to debug some URL class which is failing because of some malformedurlexception, and I have no idea what's being passed into the URL (it's something -> xml -> url, I guess...)

Btw, this is my stacktrace, and it would be nice what's in the 413, 464 or 601 line!

(URL.java:601)
	at java.net.URL.(URL.java:464)
	at java.net.URL.(URL.java:413)
	at org.apache.xerces.impl.XMLEntityManager.setupCurrentEntity(Unknown Source)
	at org.apache.xerces.impl.XMLVersionDetector.determineDocVersion(Unknown Source)
	at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
	at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
	at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
	at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
	at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
	at org.apache.avalon.framework.configuration.DefaultConfigurationBuilder.build(DefaultConfigurationBuilder.java:223)
	at org.apache.avalon.framework.configuration.DefaultConfigurationBuilder.build(DefaultConfigurationBuilder.java:192)
]]>

0

you should be able to see the lines that you're interested in.

When decompiling classes using jad, you have the option to output original line numbers as comments, this should give you this information

0

Thanks Thibaut, but I don't care about the sourcecode (I have that attached to my IDE, no problem), but I'm interested in the values of the lines of code at that location while debugging the code. That information is unfortunately not available, or I haven't found a way yet.

0

thing is, unless I misunderstand http://java.sun.com/j2se/1.5.0/docs/guide/jpda/jvmdi-spec.html#GetLocalVariableTable, that when Local variable names are not present in the class file, the debugger process don't even seem to have a way to fetch the number and types of the local variables. So I guess here you run in a limitation from the JVMDI itself and not IDEA

0

Thibaut, have a look at the jira issue.
There is at least one other debugger that is able to do that.

Also if you have a look at http://java.sun.com/j2se/1.5.0/docs/guide/jpda/jvmdi-spec.html#GetLocalVariable you'll see that all that is needed to access a local variable is the slot number.
It should be very easy to deduce that slot number from the source code. AFAIK javac simply assigns slots parameters first, then local variables in order of declaration.

0

well I guess nothing prevents the debugger to try all slots until it gets an JVMDI_ERROR_INVALID_SLOT, you're right.
you also need to know the type of the variable, but I guess trial and error can get that too as the error returned is not the same one, even though it may be sluggish

0

Huh?
Why try all slots? Why guess the type?
That information can easily be deduced from source code (resp. PSI).

0

well I see at least 2 problems
- THere is no guarantee the "source code" is the one that was compiled into the bytecode currently being executed
- compilers may do weird things, for optimization or whatever. like reusing local variable slots for example


Furthermore you have no idea what compiler was used to compile the original source, jikes ? sun javac ? ibm javac ? For having played a bit with programming a bytecode decompiler, I can tell they do not produce the same bytecode when given the same source file

0

I just tried it in Eclipse, and Eclipse is confused about the argument names (arg0, arg1, etc), but it does show the content of the variables. So, it should be possible.

0

I see the problem with the source code being out of sync.
However if that is so, then local variables are the least of your problems.

As for the different compilers: That may really eventually be a problem.
You probably are more familiar with byte code than me.

From a quick look at the VM specification it seems to me that at least for
parameters, the scheme should work:

3.6.1 Local Variables
...
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.

For local variable chances are an optimizing compiler can break the scheme:

7.2 Use of Constants, Local Variables, and Control Constructs
...
The use (and reuse) of local variables is the responsibility of the compiler writer.

However to be able to debug at all the class must be compiled with at least
some level of debug information, which may disable some optimizations.
Also I think that nowadays most optimization is left to the native (hotspot)
compiler, right?

So it should really be very quick and easy for JetBrains to be able to show
parameter values in JDK code.
To do the same for local variable would require some more testing with existing
compilers.


Thibaut wrote:

well I see at least 2 problems
- THere is no guarantee the "source code" is the one that was compiled into the bytecode currently being executed
- compilers may do weird things, for optimization or whatever. like reusing local variable slots for example


Furthermore you have no idea what compiler was used to compile the original source, jikes ? sun javac ? ibm javac ? For having played a bit with programming a bytecode decompiler, I can tell they do not produce the same bytecode when given the same source file

0

Hello Erik,

You can download a debug build of JDK 6 (which doesn't have the debug info
stripped) from http://download.java.net/jdk6/

I'm trying to debug some code, and I enter classes like java.net.URL
etc... but when I want to debug a variable there, IntelliJ says:
"Debug info unavailable".

So, my question is: How can I make it available? Do I need to enable
some options? Turn classic VM off? Something else??


--
Dmitry Jemerov
Development Lead
JetBrains, Inc.
http://www.jetbrains.com/
"Develop with Pleasure!"


0

Great, thanks! Actually, I'm using JDK 1.5, but I can't find a debug version for that...

Edited by: Erik Pragt on Jun 16, 2008 10:40 AM

0

Hi,

I downloaded the Java SE 6 version from dev.java.net . But that does not help the cause. I am facing the same problem.

Also did you find the solution for J2sdk 1.4 or java SE 5.

0

Please sign in to leave a comment.