This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 81637 - possible race condition between toggleBpt and current line?
Summary: possible race condition between toggleBpt and current line?
Status: RESOLVED FIXED
Alias: None
Product: debugger
Classification: Unclassified
Component: Java (show other bugs)
Version: 6.x
Hardware: Sun All
: P3 blocker (vote)
Assignee: Martin Entlicher
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-08-01 22:38 UTC by ivan
Modified: 2009-11-05 15:17 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

Attachments
Stack of calling of the EditorContextImpl.getCurrentLineNumber() (3.05 KB, image/png)
2007-01-10 14:53 UTC, Miloslav Metelka 		Details
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description ivan 2006-08-01 22:38:39 UTC 
ToggleBreakpointActionProvider.doAction() in both jpda and the
native debugger uses the "current line" to set a bpt on. I was
worried that this might be problematic: what if the current line
isn't where you toggled? Turns out the act of clicking in the
gutter moves the current line (cursor).

However, I just observed one instance where the cursor was on
a different line from where I was clicking in the glyph gutter 
and the bpt ended up at the line with the cursor not where I was 
clicking for a bpt.

Could I please ask someone to review the data paths in the editor and
double check that the current line is set before the action is delivered to
the debugger.
Comment 1 Martin Entlicher 2006-09-07 14:33:06 UTC 
This is a request for the editor I believe...
Debugger just registeres an action into text/x-java/GlyphGutterAction, the call
comes from the Editor...
Comment 2 Miloslav Metelka 2007-01-10 14:51:38 UTC 
I've tried to reproduce the issue but I was not successful.
Anyway I've tracked the code and ToggleBreakpointActionProvider calls
EditorContextImpl.getCurrentLineNumber(). However for some reason it's not done
in AWT (stack attached). IMHO the line number should be grabbed in AWT to
prevent symptoms of this issue. Reassigning to debuggerjpda for further evaluation.
Comment 3 Miloslav Metelka 2007-01-10 14:53:12 UTC 
Created attachment 37228 [details]
Stack of calling of the EditorContextImpl.getCurrentLineNumber()
Comment 4 ivan 2007-01-10 20:25:46 UTC 
The important thing is that the line number be set by the editor before the
callback registered by the debugger is called. Can you "prove" that these
happen serially?
Comment 5 Martin Entlicher 2007-01-11 13:24:25 UTC 
There are associated issue #90147 and issue #90142.
It's true that EditorContextImpl.getCurrentLineNumber() should be called in AWT
as a direct response to the mouse click. Currently
org.netbeans.modules.debugger.ui.actions.DebuggerAction reschedules that into a
RequestProcessor. We likely need to modify ToggleBreakpointActionProvider and
override postAction().
Comment 6 Peter Pis 2008-04-10 22:54:14 UTC 
Changing TM for open issues.
Comment 7 Martin Entlicher 2009-11-05 15:17:21 UTC 
This was already fixed - ToggleBreakpointActionProvider overrides postAction().
See also related issue #172431.