bugGNU Octave - Bugs: bug #47675, Breakpoint conditions get...

 
 

bug #47675: Breakpoint conditions get corrupted when edited in the GUI

Submitter:  Lachlan Andrew <lachlan>
Submitted:  Tue 12 Apr 2016 11:28:07 AM UTC
   
 
Category:  GUI Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Fixed Assigned to:  lachlan
Originator Name:  Lachlan Open/Closed:  * Closed
Release:  * dev Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Fri 29 Apr 2016 05:48:30 PM UTC, comment #6: 

Rik, I'm assuming you mean that the breakpoints are lost internally even though the GUI is showing markers in the editor. 

My guess would be that the issue stems from the fact that internally, if I recall correctly, breakpoints are all cleared for a file whenever there is a change in the file date, i.e., a save is done in the GUI.  It was years ago that I looked at the breakpoint code, and I think I added a marker object that can keep track of its original line number and edited line number so that breakpoints could be reinstated after a save.  I believe this is the code this patch targets with some new feature "condition" that I can't recall.

Anyway, I've not looked closely at the code, but what you are seeing could be a timing issue.  The GUI currently sets/clears breakpoints using the special callback routines, last I remember.  And I don't recall there being any type of MUTEX or timing control across threads.  So maybe what you are seeing is a situation in which the GUI saves the file and updates the breakpoints before the core (in a different thread) notices the file change.  Maybe the GUI needs to save the file, somehow force an update to dbstatus so that the core realizes the file has been changed, and then update the breakpoints.  (How to get the core to do something in proper sequence?  I proposed/programmed a background queue some time ago.)

Dan Sebald <sebald>
Thu 28 Apr 2016 04:09:00 AM UTC, comment #5: 

There is still something suspect going on.  After playing around and using the up-arrow to retrieve history for dbstatus I find that occasionally all the breakpoints are cleared.

Since I can't reliably reproduce it I'll let it go for now.  I pushed the cset here (http://hg.savannah.gnu.org/hgweb/octave/rev/b4354327d2b5).

Rik <rik5>
Group administrator
Sat 16 Apr 2016 09:15:22 PM UTC, comment #4: 

@Lachlan:
The example you posted in comment #1 works fine with the patch. No corrupted conditional breakpoints.

Philip Nienhuis <philipnienhuis>
Group Member
Wed 13 Apr 2016 10:26:24 PM UTC, comment #3: 

Thanks for reviewing the patch, Dan.  Yes, it does seem to me to fix the symptoms.  I didn't trace the execution for the particular instance that I described, but a typical example of the problem is below.

Without the patch, if bp is non-zero results in the connections being remade, then report_marker_linenr gets called multiple times for each marker, and so save-and-restore creates multiple markers for each line.  Editing the condition only edits the condition of one of those markers.

If you can suggest any further tests, I'm happy to perform them.

Lachlan Andrew <lachlan>
Wed 13 Apr 2016 06:28:18 PM UTC, comment #2: 

Your changes look reasonable, does it fix the problem?  You are clearing the breakpoint conditions at the same time the line numbers are cleared; makes sense.  Also, you are conditioning the Qt connections on the creation of the breakpoint.  My guess is that in the unmodified case, if bp not-equal 0 then there is probably some random connection or off-by-one association of the condition list and the markers.

Dan Sebald <sebald>
Wed 13 Apr 2016 10:05:40 AM UTC, comment #1: 

I forgot to mention how to replicate this error.

Create the file tmp.m containing


a = 1;
b = 2;
c = 3;


Type


dbstop in tmp at 1 if 1
dbstop in tmp at 2 if 2
dbstop in tmp at 3 if 3


Right click on line 1, and change the condition to '4'.  Save the file twice (don't ask me why...), and then observe that dbstatus gives


breakpoint in fred at line 1 if 4
breakpoint in fred at line 2 if 4
breakpoint in fred at line 3 if 3


even though the breakpoint at line 2 was not explicitly changed.

Lachlan Andrew <lachlan>
Tue 12 Apr 2016 11:28:07 AM UTC, original submission:  

When editing the condition of a breakpoint, or when breakpoints are reloaded after saving a file, the conditions get corrupted.  In particular, the condition of one breakpoint may be assigned to a different breakpoint.

This has two causes.  One is that signals are assigned multiple times to the same marker when the condition is edited.  The other is that the list of conditions is not cleared some times when it should be.

I'll attach a patch once I have the bug number.

Lachlan Andrew <lachlan>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by philipnienhuis
  • -email is unavailable- added by sebald (Posted a comment)
  • -email is unavailable- added by lachlan (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-04-28 rik5 StatusPatch Submitted Fixed
        Open/ClosedOpen Closed
    2016-04-17 philipnienhuis Carbon-Copy- Added philipnienhuis
    2016-04-12 lachlan Attached File- Added bug_47675_GUI_bp_edits.cset, #36903
        StatusNone Patch Submitted
        Assigned toNone lachlan

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code