Add a New Comment (Rich Markup)
Comment Type & Canned Response: None None > Multiple Canned Responses Fixed in development Crash with no stack trace Already fixed in newer version Fixed in stable Bad description Bad description and crash Bad stack trace Obsolete version Duplicate and not fixed Duplicate and needs more info Duplicate and fixed Need info and old
@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.
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)
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.
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
class_constructors[name] = retval;
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.
dbstop @ftp/mget ans = 36 dbstatus breakpoint in mget at line 36.
Using gdb I stopped the code in the delete_breakpoint routine in pt-stmt.cc. I then executed
dbstop @ftp/ftp dbstatus
And sure enough, the delete_breakpoint routine is called. The backtrace is
#0 tree_statement_list::delete_breakpoint (this=0xadd8d0, line=48) at parse-tree/pt-stmt.cc:193 #1 0x00007ffff7321f3d in tree_statement_list::remove_all_breakpoints (this=0xadd8d0, file=...) at parse-tree/pt-stmt.cc:258 #2 0x00007ffff728d96d in octave_user_function::~octave_user_function (this=0xaddae0, __in_chrg=<optimized out>) at octave-value/ov-usr-fcn.cc:223 #3 0x00007ffff728db36 in octave_user_function::~octave_user_function (this=0xaddae0, __in_chrg=<optimized out>) at octave-value/ov-usr-fcn.cc:237 #4 0x00007ffff6e3024c in octave_value::operator= (this=0xaddd98, a=...) at ./octave-value/ov.h:357 #5 0x00007ffff76e9db2 in symbol_table::fcn_info::fcn_info_rep::load_class_constructor ( this=0xab14f0) at corefcn/symtab.cc:433 #6 0x00007ffff76ea052 in symbol_table::fcn_info::fcn_info_rep::load_class_method (this=0xab14f0, dispatch_type=...) at corefcn/symtab.cc:472 #7 0x00007ffff76ebf21 in symbol_table::fcn_info::fcn_info_rep::find_method (this=0xab14f0, dispatch_type=...) at corefcn/symtab.cc:1011 #8 0x00007ffff6e53eb0 in symbol_table::fcn_info::find_method (this=0xaddc18, dispatch_type=...) at corefcn/symtab.h:1030 #9 0x00007ffff6e53f61 in symbol_table::find_method (name=..., dispatch_type=...) at corefcn/symtab.h:1506 #10 0x00007ffff76ed50c in symbol_table::find_function (name=..., args=..., local_funcs=true) at corefcn/symtab.cc:1285 #11 0x00007ffff73fd363 in get_user_code (fname=...) at corefcn/debug.cc:186 #12 0x00007ffff73febba in bp_table::do_get_breakpoint_list (this=0xa22a80, fname_list=...) at corefcn/debug.cc:579 #13 0x00007ffff7402722 in bp_table::get_breakpoint_list (fname_list=...) at corefcn/debug.h:97 #14 0x00007ffff73ff5f8 in Fdbstatus (args=..., nargout=0) at corefcn/debug.cc:808 #15 0x00007ffff71a7dc9 in octave_builtin::do_multi_index_op (this=0x6b8900, nargout=0, args=..., lvalue_list=0x0) at octave-value/ov-builtin.cc:132 #16 0x00007ffff71a7c48 in octave_builtin::do_multi_index_op (this=0x6b8900, nargout=0, args=...) at octave-value/ov-builtin.cc:100 #17 0x00007ffff7299a42 in octave_value::do_multi_index_op (this=0x7fffffffc510, nargout=0, idx=...) at octave-value/ov.cc:1353 #18 0x00007ffff730524a in tree_identifier::rvalue (this=0x7d6c10, nargout=0, lvalue_list=0x0) at parse-tree/pt-id.cc:97 #19 0x00007ffff7305c47 in tree_identifier::rvalue (this=0x7d6c10, nargout=0) at parse-tree/pt-id.h:109 #20 0x00007ffff7305472 in tree_identifier::rvalue1 (this=0x7d6c10, nargout=0) at parse-tree/pt-id.cc:121 #21 0x00007ffff7300baa in tree_evaluator::visit_statement (this=0x7ffff7dd3f18, stmt=...) at parse-tree/pt-eval.cc:753 #22 0x00007ffff7321afc in tree_statement::accept (this=0x7d6c90, tw=...) at parse-tree/pt-stmt.cc:178 #23 0x00007ffff7300e16 in tree_evaluator::visit_statement_list (this=0x7ffff7dd3f18, lst=...) at parse-tree/pt-eval.cc:803 #24 0x00007ffff732211c in tree_statement_list::accept (this=0xaddc30, tw=...) at parse-tree/pt-stmt.cc:291 #25 0x00007ffff7723b2d in main_loop () at corefcn/toplev.cc:593 #26 0x00007ffff6e2ecdb in octave_execute_interpreter () at octave.cc:888 #27 0x0000000000402b69 in main (argc=9, argv=0x7fffffffc9c8) at main-cli.cc:42
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
octave:1> version ans = 3.6.4 octave:2> dbstop @ftp/ftp ans = 29 octave:3> f = ftp("ftp.gnu.org") stopped in /usr/share/octave/3.6.4/m/@ftp/ftp.m at line 29 29: if (nargin == 0) debug> dbcont FTP Object host: ftp.gnu.org user: anonymous dir: / mode: binary octave:4> dbstatus octave:5> f = ftp("ftp.gnu.org") FTP Object host: ftp.gnu.org user: anonymous dir: / mode: binary
(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)
Attach Files: Comment:
Depends on the following items: None found
Items that depend on this one: None found
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 project members can vote.
Please enter the title of George Orwell's famous dystopian book (it's a date):
Follow 3 latest changes.
Copyright © 2023 Free Software Foundation, Inc. Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved. The Levitating, Meditating, Flute-playing Gnu logo is a GNU GPL'ed image provided by the Nevrax Design Team. Source Code
Powered by Savane 3.9