bugGNU Octave - Bugs: bug #46451, unable to set breakpoints within...


bug #46451: unable to set breakpoints within classdef classes

Submitted by:  Carnë Draug <carandraug>
Submitted on:  Sun 15 Nov 2015 07:15:32 PM UTC  
Category:  Interpreter Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Feature Request
Status:  In Progress Assigned to:  None
Originator Name:  Open/Closed:  Open
Release:  dev Operating System:  Any

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)

Tue 26 Mar 2019 03:16:22 AM UTC, comment #14: 

The problem with command syntax mentioned in comment #3 was fixed in


See also bug #55891.

After changeset


setting breakpoints in classdef methods using dbstop commands like


Some additional changes will be needed to accept filenames in addition to class names and to support parsing class names or methods names when they are prefixed by package names and to also allow breakpoints in classdef methods to be set from inside the GUI editor.  But this change is a good start.

See also bug #45404.

John W. Eaton <jwe>
Project Administrator
Tue 12 Feb 2019 02:56:41 PM UTC, comment #13: 

After the fixes to bug #47680, command-style function calls of the form

dbstop @ftp/dir

no longer work.

I'd like to make dbstop compatible with Matlab for setting breakpoints in classdef methods.  In addition to the syntax shown in comment #12, does anything else work?  The Matlab docs show

dbstop in file
dbstop in file at location
dbstop in file if expression
dbstop in file at location if expression

and also say that FILE may be of the form "file>function".  Does that syntax work for class methods or local functions in a classdef file?

The docs also say that LOCATION may be the name of a local function in the file, but they don't explicitly state that the function name may be in the form shown in comment #12 or explain that "local function" may be a classdef method.

John W. Eaton <jwe>
Project Administrator
Tue 15 May 2018 10:10:11 AM UTC, comment #12: 

FYI, none of the syntax options for this mentioned by the original poster work in Matlab either. What does work in Matlab is something the following:

dbstop method_debug_test at method_debug_test.bar

where method_debug_test.m is the classdef file and it has a method called bar

See also: https://stackoverflow.com/questions/19523965/how-to-place-a-breakpoint-at-the-start-of-a-method-programmatically

Richard <crobar>
Sun 02 Apr 2017 10:40:21 PM UTC, comment #11: 

I had the same problem on Octave when testing pmtk3 package, on Ubuntu 16.04
error: remove_breakpoint: unable to find the requested function

I tried to apply the patch but it did not work. Can you please publish the Ubuntu patch?

Multiple thanks!!

Sammy Jankis <piux>
Sun 19 Jun 2016 11:30:50 AM UTC, comment #10: 

Hi there,

I am new to Octave and I was wondering if I can apply the patch mentioned below in order to repair my Octave 4.0.2 on Windows.

Can someone give some hint about how I can find out to proceed?


Daniel <darim>
Mon 08 Feb 2016 12:27:55 AM UTC, comment #9: 

Unfortunately I'm not that familiar with the internals of classdef. About who wrote it, I believe it was mostly Michael Goffioul.

Carnë Draug <carandraug>
Project Member
Sun 27 Dec 2015 01:46:37 AM UTC, comment #8: 

Carnë, the attached patch allows breakpoints to be set with the syntax
dbstop  classname>method
Could you please give it a try?

It has a memory leak.  The problem is that the classdef framework doesn't seem to keep   octave_user_function  objects around, but instead creates  octave_function  objects on the fly.  In order to keep them around long enough for the dbstatus and dbclear commnds, I'm just allocating them on the heap :(  The patch is clearly not ready to be applied, but I hope it may help someone who knows more about  classdef.  Do you know who wrote that code?


(file #35861)

Lachlan Andrew <lachlan>
Wed 23 Dec 2015 11:24:59 PM UTC, comment #7: 

I now see that I had old class definitions in my path.  Without thme, I get the same problem.  It turns out that it does find the constructor, but that it is not considered "user code" (it is not of type octave_user_function) and so doesn't set the breakpoint.

Unfortunately, the classdef framework doesn't seem to have clear "tree_statement_list" objects into which the breakpoint can be placed.  I'm intrigued by this and will keep looking into it.

Lachlan Andrew <lachlan>
Mon 21 Dec 2015 03:56:05 AM UTC, comment #6: 

Carenë, it's odd that it works for me but not for you.  Bug #46468 reports the same problem, so I'm the odd one out.  Are you using Windows?

Lachlan Andrew <lachlan>
Tue 15 Dec 2015 02:12:39 PM UTC, comment #5: 

I tried at a88142abca36 like you and continue to see "add_breakpoint: unable to find the requested function"

This is the same I saw on 4.0.0 and 8da80da1ac37 (current tip of default branch).

Carnë Draug <carandraug>
Project Member
Tue 15 Dec 2015 03:48:26 AM UTC, comment #4: 


I just re-checked it on the default branch at changeset a88142abca36 ("Remove spurious tick labels occurring when setting ticks and removing tick labels")

Even though it doesn't appear in dbstatus, it does appear to stop in that function:

>> dbstop ("@inputParser/inputParser")
ans =  130
>> inputParser
stopped in /usr/share/octave/packages/general-1.3.2/@inputParser/inputParser.m atline 130
130:   if (nargin != 0)

Running  dbstatus  clears the breakpoint, as described in bug #41190.

Lachlan Andrew <lachlan>
Mon 14 Dec 2015 07:27:37 PM UTC, comment #3: 

What octave version are you using that returns:

>> dbstop ("@inputParser/inputParser")

ans = 130

Carnë Draug <carandraug>
Project Member
Sat 12 Dec 2015 10:18:22 PM UTC, comment #2: 

Oops.  I spoke too soon.  Although it reported a line number, it didn't show up in dbstatus.  I'll keep investigating.

Lachlan Andrew <lachlan>
Sat 12 Dec 2015 09:53:57 AM UTC, comment #1: 


>> dbstop ("@inputParser/inputParser")

ans =  130

I think the bug is in the documentation.  Should I post a patch?

Lachlan Andrew <lachlan>
Sun 15 Nov 2015 07:15:32 PM UTC, original submission:  

It seems that it is not possible to set a breakpoint within a classdef class.

octave> dbstop ("inputParser")
error: add_breakpoint: unable to find the requested function

octave> dbstop ("inputParser.inputParser")
error: unknown package `inputParser'
error: add_breakpoint: unable to find the requested function

octave> dbstop ("inputParser/inputParser")
error: add_breakpoint: unable to find the requested function

octave> dbstop ("inputParser/inputParser")
error: add_breakpoint: unable to find the requested function

octave> dbstop ("inputParser.addRequired")
error: add_breakpoint: unable to find the requested function

octave> dbstop ("inputParser/addRequired")
error: add_breakpoint: unable to find the requested function

This may be related with not being able to define a classdef on the interpreter or why "which" does not associate it with a file.

Carnë Draug <carandraug>
Project Member


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

Attach Files:

Attached Files
file #35861:  bug_46451.patch added by lachlan (5KiB - text/x-diff)


Carbon-Copy List
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by crobar (Posted a comment)
  • -email is unavailable- added by piux (Posted a comment)
  • -email is unavailable- added by darim (Posted a comment)
  • -email is unavailable- added by lachlan (Posted a comment)
  • -email is unavailable- added by carandraug (Submitted the item)

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

    Only project members can vote.




    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-01-31 mtmiller Dependencies- => bugs #57711 is dependent
    2019-03-26 jwe StatusNone => In Progress
    2015-12-27 lachlan Attached File- => Added bug_46451.patch, #35861
    2015-11-19 pantxo Dependencies- => bugs #46468 is dependent

    Back to the top

    Powered by Savane 3.5