JavaTM Platform Debugger Architecture
Known Bugs and Limitations
The debugged VM can crash when very large numbers of events are
generated. This is especially noticeable if you enable all method entry
and exit events for a large application.
Some events that occur at the same location are not properly combined
into event sets; instead, they are reported separately as single-element
event sets. This happens when events of different kinds occur at the same
thread and location.
The setValue method sometimes fails with an incorrect
ClassNotLoadedException when the destination Field, LocalVariable, or
ArrayReference element has an array type.
An attempt to use a StackFrame that is no longer valid (i.e. its thread
has been resumed since it was retrieved), can result in a crash in the
target VM.
Generated parser files for JDB use deprecated APIs from the
Java 2 Platform libraries.
Synthetic fields and methods are not suppressed nor are they
distinguished from non-synthetic members.
In-process debugging through the JDI is not supported.
Constructors have the name "<init>" and method style signatures,
for example the default constructor has the signature "()V".
The following bugs exist in the current Win32 classic VM JVMDI implementation
and in the Solaris Reference VM implementation.
They will be fixed in the first maintenance release of the
Java 2 SDK.
For classes compiled without -g, JDI responds to queries for
local variables with empty lists instead of throwing the appropriate
AbsentInformationException.
Some breakpoints at the start of methods are not reported if
you are also stepping over the method invocation.
Incorrect local variable values are reported during method exit events.
Redundant step events are generated when instruction stepping through
quicked instructions for the first time.
The current production release of the Sun
SolarisTM VM cannot be
used with this release. The Solaris Reference implementation can be used,
however, with the limitations listed above.
