bugGNU Octave - Bugs: bug #33411, Breakpoints aren't hit with run...

 
 

bug #33411: Breakpoints aren't hit with run command

Submitted by:  Jordi Gutiérrez Hermoso <jordigh>
Submitted on:  Thu 26 May 2011 08:41:53 PM UTC  
 
Category: InterpreterSeverity: 2 - Minor
Priority: 2Item Group: Feature Request
Status: FixedAssigned to: Lachlan Andrew <lachlan>
Originator Name: Open/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)

Mon 16 May 2016 05:46:50 AM UTC, comment #20:

I changed the already_existed variable name to delete_fcn since it seemed clearer. I checked in the changeset here http://hg.savannah.gnu.org/hgweb/octave/rev/4c080cbc4ef9.

The issue with having to type dbcont twice is because the isdir script is called when print_usage() is invoked. See the transcript below where I set a breakpoint in isdir ("dbstop isdir") before proceeding with another breakpoint and dbcont.

Closing report.

Rik <rik5>
Project Administrator
Tue 03 May 2016 01:14:35 PM UTC, comment #19:

What I saw is that upon typing "dbcont" the "instruction pointer" jumps back from the print_usage line in the if block to the preceding if condition itself.
As if isdir.m is called by print_usage() ... ?

Philip Nienhuis <philipnienhuis>
Project Member
Tue 03 May 2016 12:28:52 PM UTC, comment #18:

Thanks for checking, Philip.

I think everything between the keyboard and chair is in perfect working order. I've sometimes noticed that dbcont has to be issued twice in cases not involving "run" at all. It's probably worth looking into -- I've just ignored it until now.

Lachlan Andrew <lachlan>
Project MemberIn charge of this item.
Tue 03 May 2016 12:22:58 PM UTC, comment #17:

Finally tried the patch, sorry for the delay.

In the sequence of comment #6, "run isdir" is now interrupted properly.

What I do not understand is why I have to type "dbcont" twice to get to the end of the function, but that also happens with just "isdir". Maybe be between keyboard and chair I guess.

Philip Nienhuis <philipnienhuis>
Project Member
Thu 28 Apr 2016 08:47:36 PM UTC, comment #16:

Lachlan,

I forgot to cc myself (now done) so forgot all about this bug, sorry for that. Happens with more bugs I try, I should be more careful in that respect.
Somewhere in the next days I'll try the new patch.

Philip Nienhuis <philipnienhuis>
Project Member
Fri 15 Apr 2016 01:35:56 PM UTC, comment #15:

It's getting late. This time for sure...

(file #36939)

Lachlan Andrew <lachlan>
Project MemberIn charge of this item.
Fri 15 Apr 2016 01:34:22 PM UTC, comment #14:

Oops, this is the file I meant...

(file #36938)

Lachlan Andrew <lachlan>
Project MemberIn charge of this item.
Fri 15 Apr 2016 12:57:49 PM UTC, comment #13:

The attached patch should now work for functions as well as scripts. Instead of testing for "is_user_script", it checks for "is_user_code", which is true for either scripts or functions.

I've also updated the documentation for source().

When you get time, let me know how it goes.

(file #36937)

Lachlan Andrew <lachlan>
Project MemberIn charge of this item.
Fri 15 Apr 2016 11:37:55 AM UTC, comment #12:

Philip, the file foo.m defines a function "foo". It is not a script. When you source the file, it places the function "foo" in the symbol table, rather than executing it. That is why it doesn't print "Hello!", and why it is a command line function after running the file.

The bug in my code is that I call "find" to see if the symbol is already in the symbol table, but I didn't realise that "find" actually loads the symbol. Thus, after the find(), "foo" already points to the function and is not considered a "script".

I'll have to find a way to query the symbol table without loading a symbol.

Lachlan Andrew <lachlan>
Project MemberIn charge of this item.
Tue 12 Apr 2016 07:12:14 PM UTC, comment #11:

You mean what I saw in comment #2 of bug # 47585?

That still behaves the same.
Intriguing, and only noting now, is that I didn't see "Hello!" printed to the screen invoking "run foo", with or without breakpoint.

What I also see is that after "run foo" "dbclear foo" does nothing.
After closing foo.m editor tab and reopening foo.m in the editor, the breakpoint is cleared and there's no way to put it back.....
as if foo.m disappeared out of some memory slot.

Oh I accidentally hit a clue:

... so it morphed into a command line function instead of a .m function on disk, apparently after the command "run foo".

Philip Nienhuis <philipnienhuis>
Project Member
Thu 07 Apr 2016 07:35:55 AM UTC, comment #10:

I've just noticed that I forgot to upload the revised patch.

Philip, can you see if this fixes the problems you saw at bug #47585?

(file #36851)

Lachlan Andrew <lachlan>
Project MemberIn charge of this item.
Mon 08 Feb 2016 05:06:55 AM UTC, comment #9:

(Oops, I just noticed it was Philip who kindly tested the patch. Sorry for calling you Rik.)

I've reassigned this from Jordi to me.

Lachlan Andrew <lachlan>
Project MemberIn charge of this item.
Sun 31 Jan 2016 06:42:10 AM UTC, comment #8:

Rik, it turns out that the reason run isdir didn't return anything is that run does nothing if its argument is a function not a script.

I've extended the patch to throw an error if the argument to source (used by run) exists but is not a script. It still silently returns if the file doesn't exist, so that we don't get an error about ./.octaverc not existing.

The existing code also has a memory leak where the parse tree of the newly parsed file is not deleted if it is not a script. The patch fixes that too.

(My previous post was also too rushed; I thought that the error messages were for the run case, not for calling isdir directlly.)

Lachlan Andrew <lachlan>
Project MemberIn charge of this item.
Sat 30 Jan 2016 11:20:47 PM UTC, comment #7:

Thanks for the prompt reply, Rik.

You understand perfectly. I just checked that it stops, but didn't check that it continues :( One day I'll stop rushing...

I'll look into it and get back to you.

Lachlan Andrew <lachlan>
Project MemberIn charge of this item.
Sat 30 Jan 2016 10:34:28 PM UTC, comment #6:

Lachlan, after applying your patch to 4.1.0+:

I may not understand fully, but isn't the breakpoint supposed to be hit when doing "run isdir", similarly to just "isdir" ?

Philip Nienhuis <philipnienhuis>
Project Member
Sat 30 Jan 2016 11:38:17 AM UTC, comment #5:

The attached changeset fixes this bug.

The remaining idiosyncrasy is that if filename.m has a breakpoint, and we "run /other/path/ending/filename.m" then the breakpoint is cleared.

I look forward to this five year old bug being closed.

(file #36208)

Lachlan Andrew <lachlan>
Project MemberIn charge of this item.
Tue 25 Jun 2013 04:13:22 PM UTC, comment #4:

The problem is still open, so the bug should remain open. I won't be working on this, though.

Jordi Gutiérrez Hermoso <jordigh>
Project Administrator
Sat 22 Jun 2013 02:15:55 AM UTC, comment #3:

Jordi, do you want to continue with this bug report? Or can it be closed?

Rik <rik5>
Project Administrator
Mon 30 May 2011 07:17:06 AM UTC, comment #2:

Btw, asking around, I think Matlab behaves differently here. Doing "run" on a function file executes the function defined there, but apparently it's impossible to pass it parameters with this syntax. Since Octave allows defining functions in a script file unlike Matlab, perhaps this different behaviour should persist? In which case your suggestions would apply.

Jordi Gutiérrez Hermoso <jordigh>
Project Administrator
Fri 27 May 2011 05:21:47 AM UTC, comment #1:

Just to clarify, the run function doesn't run other functions. It can only run other scripts since it sources the named file. If you source a function file, you will just define the function, not execute it. So I assume that your file foo.m is a script file. Is that correct?

Also, if you plan to work on this, you might want to look at the functions load_out_of_date_fcn and out_of_date_check in symtab.cc. Those functions do something similar to what we probably want, except that they start with an octave_function object (which can be a script) and we only have the name of a script file.

What we may want to do is find out if there is already a script loaded in the symbol table from the same file that we are being asked to run, then check to see whether the already parsed script is out of date. If it is, we need to parse the file again. If not, then we should skip the parse step and execute the octave_user_script object that we found in the symbol table.

I suppose all of that could go inside the source function itself, then both run and source will be fixed. Unless you think that the source function should not bother with this optimization and should always parse the file. But if that is the case, then I don't see why the run function should behave any differently.

John W. Eaton <jwe>
Project Administrator
Thu 26 May 2011 08:41:53 PM UTC, original submission:

If you set a breakpoint with

but use the run command instead of just using the function's name
Then the breakpoint isn't hit. See this discussion: http://octave.1599824.n4.nabble.com/dbstop-doesn-t-break-with-run-script-td3551242.html

Jordi Gutiérrez Hermoso <jordigh>
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 #36851:  bug_33411.v2.cset added by lachlan (4KiB - text/x-diff)
file #36208:  bug_33411.cset added by lachlan (3KiB - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    Date Changed By Updated Field Previous Value => Replaced By
    Mon 16 May 2016 05:46:50 AM UTCrik5StatusIn Progress=>Fixed
      Open/ClosedOpen=>Closed
    Thu 28 Apr 2016 08:47:36 PM UTCphilipnienhuisCarbon-Copy-=>Added philipnienhuis
    Fri 15 Apr 2016 02:04:34 PM UTClachlanAttached File#36939=>Removed
    Fri 15 Apr 2016 02:04:03 PM UTClachlanAttached File-=>Added bug_33411_dbstop_run.v3.cset, #36940
    Fri 15 Apr 2016 01:35:56 PM UTClachlanAttached File-=>Added bug_33411_dbstop_run.v3.cset, #36939
    Fri 15 Apr 2016 01:35:23 PM UTClachlanAttached File#36938=>Removed
    Fri 15 Apr 2016 01:34:22 PM UTClachlanAttached File-=>Added bug_33411_dbstop_run.v3.cset, #36938
    Fri 15 Apr 2016 01:32:59 PM UTClachlanAttached File#36937=>Removed
    Fri 15 Apr 2016 12:57:49 PM UTClachlanAttached File-=>Added bug_33411_dbstop_run.v3.cset, #36937
    Thu 14 Apr 2016 11:47:23 PM UTClachlanStatusPatch Submitted=>In Progress
    Thu 07 Apr 2016 07:35:55 AM UTClachlanAttached File-=>Added bug_33411.v2.cset, #36851
    Mon 08 Feb 2016 05:06:55 AM UTClachlanItem GroupIncorrect Result=>Feature Request
      StatusConfirmed=>Patch Submitted
      Assigned tojordigh=>lachlan
    Sat 30 Jan 2016 11:38:17 AM UTClachlanAttached File-=>Added bug_33411.cset, #36208
    Tue 25 Jun 2013 04:13:22 PM UTCjordighStatusIn Progress=>Confirmed
    Sat 22 Jun 2013 02:15:55 AM UTCrik5Priority5 - Normal=>2

    Back to the top


    Powered by Savane 3.1-cleanup1