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

 
 

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

Submitted by:  Lachlan Andrew <lachlan>
Submitted on:  Tue 12 Apr 2016 11:28:07 AM UTC  
 
Category: GUISeverity: 3 - Normal
Priority: 5 - NormalItem Group: Incorrect Result
Status: FixedAssigned to: Lachlan Andrew <lachlan>
Originator Name: LachlanOpen/Closed: Closed
Release: devOperating System: GNU/Linux

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission 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>
Project 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>
Project 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>
Project MemberIn charge of this item.
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

Type

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

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

Lachlan Andrew <lachlan>
Project MemberIn charge of this item.
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>
Project MemberIn charge of this item.

 

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

Attach File(s):
   
   
Comment:
   

Attached Files

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 6 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Thu 28 Apr 2016 04:09:00 AM UTCrik5StatusPatch Submitted=>Fixed
      Open/ClosedOpen=>Closed
    Sun 17 Apr 2016 12:27:56 PM UTCphilipnienhuisCarbon-Copy-=>Added philipnienhuis
    Tue 12 Apr 2016 11:31:26 AM UTClachlanAttached File-=>Added bug_47675_GUI_bp_edits.cset, #36903
      StatusNone=>Patch Submitted
      Assigned toNone=>lachlan

    Back to the top


    Powered by Savane 3.1-cleanup1