Community
Participate
Working Groups
This is a 1.0 stream stop-ship! How to reproduce the bug: - Publish and run the JSPandServletExample - Run the Form example and get the result page - Set a breakpoint in FormServletResultPage.jsp - Refresh the browser on the result page (it's not necessary to go back to the input form, just Refresh the result page) - Debugger stops on breakpoint correctly. Resume and run to completion to display the JSP output. - Remove the breakpoint - Touch the JSP file and save it - Refresh the browser on the result page - The JSP gets regenerated into .java, the .java gets compiled into .class, but the browser hangs without displaying any output - If you Refresh the browser again the result page will be displayed - If you try to stop the server it won't stop successfully and you have to terminate it. Even after you terminate it, the Debug view still shows an active Server Launcher process. Following these steps, you will notice this bug every time. The problem is that JDIDebugTarget.lineBreakpointRemoved(IMarker) makes the following call, which always returns too early on PatternBreakpoints because the breakpoint never has a type (only a pattern): ... String name= getTopLevelTypeName(breakpoint); if (name == null) { internalError(ERROR_BREAKPOINT_NO_TYPE); return; } List markers= (List) fDeferredBreakpointsByClass.get(name); if (markers == null) { return; } markers.remove(breakpoint); if (markers.isEmpty()) { fDeferredBreakpointsByClass.remove(name); } }
Proposed fix follows. This fixes the reported bug, but may have adverse side effects. I will spend some more time investigating the consequences of this fix. Add the following method to PatternDebugTarget protected void lineBreakpointRemoved(IMarker breakpoint) { if (!PatternDebugModel.isPatternBreakpoint(breakpoint)) { super.lineBreakpointRemoved(breakpoint); return; } List list = removeBreakpointRequests(breakpoint); if (list != null) { //installed breakpoint Iterator iter = list.iterator(); while (iter.hasNext()) { BreakpointRequest request = (BreakpointRequest)iter.next(); try { // cannot delete an expired request if (!isExpired(request)) { getEventRequestManager().deleteEventRequest(request); // disable & remove } } catch (VMDisconnectedException e) { return; } catch (RuntimeException e) { internalError(e); } } } //deferred breakpoint if (!breakpoint.exists()) { //resource no longer exists return; } String name= getPattern(breakpoint); if (name == null) { internalError(ERROR_BREAKPOINT_NO_TYPE); return; } List markers= (List) fDeferredBreakpointsByClass.get(name); if (markers == null) { return; } markers.remove(breakpoint); if (markers.isEmpty()) { fDeferredBreakpointsByClass.remove(name); } }
PatternDebugTarget.defer(IMarker, String) did not check the list before adding the marker it was attempting to defer. Adding this check allows breakpoints to be removed: if (!bps.contains(breakpoint)) { bps.add(breakpoint); }
Need to ensure the same problem does not exist in 2.0
Reduced severity to normal - not ciritcal for stable Dec 07 build.
Fixed in Rollup 1. Need to ensure that we work in 2.0.
Fixed in 2.0
Verified by Jay Cagle
