Name: chT40241 Date: 03/09/98


When a program is debugged with jdb, and during the program's execution some class fails class resolution or initialization, it may thereafter become impossible to set breakpoints in methods of unrelated classes.

To reproduce the problem, debug the Microsoft Visual J++ sample applet under HotJava 1.1.2. I used the following commands to cause the problem:

jdb -Dhotjava.home=D:\HotJava sun.hotjava.Main \ FILE:D:\Sample\Sample.html
stop in Sample.init
run
next
stop in Sample.displayImage

The second stop in command fails due to a NoClassDefFoundError exception. If the second stop in is entered immediately following the first, it succeeds.

What has happened is as follows. During the execution of run, HotJava
attempts to load the class sunw.hotjava.security.SecureGlue. During
resolution of this class, the class sun.security.jsafe.Provider is
called for but cannot be found. This causes NoClassDefFoundError to be thrown, but apparently HotJava catches the exception and is able to
recover. Nevertheless, it appears that the binary class for
sunw.hotjava.security.SecureGlue has been added to binclasses.

When jdb receives the stop in command, its first action is to obtain
a RemoteClass object representing the class containing the method wherein the breakpoint is to be set. sun.tools.debug implements this by asking the debug agent for a list of all classes currently defined, and then
asks each class on the list for its name (as well as other info, notably
implemented interfaces), until it finds the one wanted. Unfortunately,
sunw.hotjava.security.SecureGlue is in the list, and an interface inquiry
directed at this class causes NoClassDefFoundError to be thrown again,
causing sun.tools.debug.RemoteAgent.getClassInfo to fail, which in turn
causes the breakpoint not to be set. Further, the error message would lead one to believe that the class in which the breakpoint was to be set was not found, which is (in this case) absurd.

There are several potential approaches to fixing this problem. The
cheapest fix is probably for the debug Agent to remove erroneous classes from the list of all classes before returning it to the debugger.
Alternatively, the debugger could ignore the failure to get info for a
particular class and simply proceed to trying the next one. The best
solution, it seems to me, would be for the debugger not to require
information about all classes to set a breakpoint for a particular class.
This would probably require significant redesign of the debugger and the
agent, so I don't expect to see it, but quite apart from this problem,
the overhead of this implementation when many classes are defined is
clearly considerable.

======================================================================