Community
Participate
Working Groups
I created a launch config type to make remote java debugging easier. The source of debuggee was on remote host only. When debugging, the source was dynamically downloaded to a local workspace project which has java nature. I set breakpoint in the source and everything looked fine. However, when I restared the next debug session, the breakpoint was restored with the label <no responding>. Breakpoint still can be hit though.
*** This bug has been marked as a duplicate of 68915 ***
Incorrectly marked as dup (I pressed commit instead of "find").
I took a look for JDT code. It looks like there is a checking if the compileunit is in classpath or not when bkp is restored. In our case, the source is downloaded dynamically by a remote source container and stored in a local project with java nature. The project is used as a container for all sources downloaded remotely, it is also used to store other lanuage source, such as C++, C. Therefore, the downloaded java source is not added to the classpath of local workspace project. I think this is a general issue for restoring bkp on remote source.
Just a note that priority is a field that is generally resevered to be changed by committers.
Fixed in BreakpointUtils. Each java breakpoint associated with a java model element has a java element handle attribute. We attempt to use this handle to generate a member name for the breakpoint (i.e. the member containing the breakpoint). When the java element goes missing, a java model exception is thrown and we put up the "not responding" label. The exception is thrown as we do a binary search for the member containing the breakpoint based on line number - but the search fails with an exception as the element no longer exists. The fix is to avoid doing the search when the enclosing type does not exist, but still return the handle of the containing type.
Also released fix to 3.0.1. Please verify, Luc.
Verified.
