bugGNU Octave - Bugs: bug #41190, dbstatus clears breakpoints set in...

 
 

bug #41190: dbstatus clears breakpoints set in @class files

Submitted by:  Rik <rik5>
Submitted on:  Fri 10 Jan 2014 04:38:00 PM UTC  
 
Category: InterpreterSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Incorrect Result
Status: FixedAssigned to: None
Originator Name: Open/Closed: Closed
Release: devOperating System: Any

Add a New Comment (Rich MarkupRich Markup):
   

You are not logged in

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

 

Sun 17 Jan 2016 09:58:00 PM UTC, comment #5:

@Lachlan: I checked in your change here http://hg.savannah.gnu.org/hgweb/octave/rev/87b3348d8d76. In the log message, unless there is ambiguity, we don't bother to put the extended path to the file name. Thus, I shortened "libinterp/core/symtab.cc" to just "symtab.cc". I'm sorry it takes so long to get used to our coding standards, but you're doing a terrific job. I've checked in 3 patches of yours today and maybe I'll have time for another.

Rik <rik5>
Project Administrator
Tue 15 Dec 2015 10:33:59 AM UTC, comment #4:

Michael is right that there is a flow problem. It is caused because find_function () calls find_method () which only looks in class_methods, whereas constructors are only put in class_constructors.

The attached patch adds the constructors to class_methods, which fixes the problem. The alternative is to check both class_methods and class_constructors in either find_method or find_function.

(file #35744)

Lachlan Andrew <lachlan>
Mon 10 Feb 2014 04:46:49 PM UTC, comment #3:

I think there something wrong in the flow. You shouldn't go through line 1011 in symtab.cc, at that point, the class constructor has already been loaded, so you shouldn't need to reload it.

I believe symbol_table::fcn_info::fcn_info_rep::find_method should do something similar to load_class_method, that is checking whether full_name() equals dispatch_type, and if true, look into class_constructors. Or at least something along those lines.

Michael Goffioul <goffioul>
Project Member
Mon 10 Feb 2014 04:36:18 PM UTC, comment #2:

Ugh. I see a bit of what is happening, but no easy way to stop it. When the list of breakpoints is generated (get_breakpoint_list), Octave goes through each breakpoint found to get details such as file name. For ordinary functions this works fine. For class objects, find_method is used which seems to invoke the whole class constructor interface. Eventually the symbol table is updated in line 433 of symtab.cc with

The assignment operator '=' triggers a look at the currently stored octave_value in class_constructors[name]. There is only one reference count to this octave_value and when it is decremented it triggers the destructor for the octave_value. In this case the octave_value is holding a user function reference and part of the destructor for removing a function from Octave is to clear any breakpoints.

So, that's why breakpoints are getting cleared. It does reveal a bit more as well, this is only a problem with the constructor. Setting a breakpoint in a different function of a class works.

Rik <rik5>
Project Administrator
Mon 10 Feb 2014 04:46:53 AM UTC, comment #1:

Using gdb I stopped the code in the delete_breakpoint routine in pt-stmt.cc. I then executed

And sure enough, the delete_breakpoint routine is called. The backtrace is

Rik <rik5>
Project Administrator
Fri 10 Jan 2014 04:38:00 PM UTC, original submission:

This came up during the resolution of bug #41126 and is reported here because it is a separate bug.

Breakpoints set in @class files appear to be cleared when dbstatus is used. This has been confirmed on 3.6.4, 3.8.0, and dev branches so it is not new.

A sample session showing the behavior is

Rik <rik5>
Project Administrator

 

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

Attach File(s):
   
   
Comment:
   

Attached Files
file #35744:  bug_41190_patch.cset added by lachlan (1kB - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by lachlan (Updated the item)
  • -unavailable- added by goffioul (Posted a comment)
  • -unavailable- added by rik5 (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 3 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sun 17 Jan 2016 09:58:00 PM UTCrik5StatusConfirmed=>Fixed
      Open/ClosedOpen=>Closed
    Tue 15 Dec 2015 10:33:59 AM UTClachlanAttached File-=>Added bug_41190_patch.cset, #35744

    Back to the top


    Powered by Savane 3.1-cleanup