bugGNU Octave - Bugs: bug #44195, segfault with dbstatus

 
 

bug #44195: segfault with dbstatus

Submitted by:  Rik <rik5>
Submitted on:  Fri 06 Feb 2015 06:15:09 AM UTC  
 
Category:  Interpreter Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Regression
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  Closed
Release:  dev Operating 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)

Sun 17 Jan 2016 03:39:17 PM UTC, comment #10: 

@Lachlan: I liked this last patch the best by far.  So simple to just make a temporary copy of the breakpoints before iterating over them.  I checked in the change under your name here (http://hg.savannah.gnu.org/hgweb/octave/rev/622e34f6ede3).

Closing report.

Rik <rik5>
Project Administrator
Tue 22 Dec 2015 01:45:35 AM UTC, comment #9: 

Here is a much simpler patch. (Sorry for the barrage of versions.  I'll try not to generate so much noise next time! :)

It simply makes a copy of  db_set  before the loop and iterates over that constant copy.  This is likely to be from the command line and so speed is not an issue.

(file #35828)

Lachlan Andrew <lachlan>
Mon 21 Dec 2015 10:24:54 AM UTC, comment #8: 

A slightly neater patch is attached.

It might need some "fuzz" to apply, since it is relative to the source with my dbstop overhaul, https://savannah.gnu.org/patch/?8784.

(file #35810)

Lachlan Andrew <lachlan>
Mon 21 Dec 2015 10:18:00 AM UTC, comment #7: 

It seems that the problem is that the call to symbol_table::find_function () in get_user_code resets the db_set data structure, and so the test   it != bp_set.end ()  in bp_table::do_get_breakpoint_list()  returns false even though there are no more items in the list.

Somehow, we need to flag that the iterator is invalid and restart the loop.  A first-cut attempt is attached.  (The indentation was not updated, so the guts of the patch can be seen.)

(file #35809)

Lachlan Andrew <lachlan>
Fri 06 Feb 2015 07:25:25 PM UTC, comment #6: 

There is a way of accomplishing the end effect if editing within the GUI's editor.  With an extra level of indirection--making the breakpoints more object like--upon editing the breakpoints can keep track of the line number they originated from before editing took place.  Then when the GUI saves the file, it can reinstate the breakpoints at the new line numbers.  See https://savannah.gnu.org/patch/?8006

Dan Sebald <sebald>
Fri 06 Feb 2015 07:06:30 PM UTC, comment #5: 

On comment #4, it's not which or help, it's the fact that the timestamp on the file was modified.  When you call an m-file Octave reads it from disk and converts it to an internal representation and stores the time stamp for when it did this.  After that the code runs out of memory, but it checks the function timestamp every time it uses the function to make sure you haven't been modifying the code. 

When the timestamp does change, regardless of whether any code itself has changed, Octave throws out the internal representation and re-reads the file from disk.  Octave doesn't know what you have changed so it deletes breakpoints and associated information about the function.

Rik <rik5>
Project Administrator
Fri 06 Feb 2015 06:20:15 PM UTC, comment #4: 

Confirmed on Linux as well.

(Perhaps nitpicking, but this only happens after the file was saved with breakpoints set.)

Some more investigation:

After saving the file to disk, upon typing
"which junk" or
"help junk",

the breakpoints are wiped as well... (?)

More investigation shows that it is saving to file that makes things wonky: even after saving an unmodified file, typing "which junk" makes the breakpoints disappear.

I suppose this is another, but related, bug - IMO breakpoints shouldn't be wiped when a function is accessed through "help" or "which".
Is another bug report needed for this, or shall we wait to see if it is all related to a deeper lying issue?

Philip Nienhuis <philipnienhuis>
Project Member
Fri 06 Feb 2015 06:04:26 PM UTC, comment #3: 

I'm running Linux and confirmed this bug.  I see

octave exited with signal 11

and consistent failure.

Dan Sebald <sebald>
Fri 06 Feb 2015 02:30:01 PM UTC, comment #2: 

It may be only Linux has a problem, although I doubt it.  I tested the CLI and GUI using run-octave with hg id 40e846a96908 and both segfaulted.

Rik <rik5>
Project Administrator
Fri 06 Feb 2015 11:21:10 AM UTC, comment #1: 

FTR, tried this under Windows with a (cross-)built 3.9.0+ and 4.1.0+ (before the merges of gui-release & default into 3.9.0+) from January 26, and a 3.9.0+ (new default branch) from Feb 1.

I did as you outlined and then all three gave:

>> edit junk.m
>> dbstop ("junk", 2)
ans =  2
>> dbstop ("junk", 4)
ans =  4
## Now, just changing 1 -> 1A
>> dbstatus
breakpoint in junk at lines 2, 4.
## Now clicked "Save file"
>> dbstatus
>>
## Breakpoints were wiped after saving the file, upon "dbstatus" cmd

so no problems there.

That said, the breakpoint bookkeeping in the editor might be less robust than desired; I've filed another bug report (#44163) about some -perhaps related- issues that do occur on Windows.

Philip Nienhuis <philipnienhuis>
Project Member
Fri 06 Feb 2015 06:15:09 AM UTC, original submission:  

Create a file junk.m with the lines

function junk ()
disp ('1');
disp ('2');
disp ('3');
endfunction

From within Octave, set two breakpoints with

dbstop ("junk", 2)
dbstop ("junk", 4)

Now use your editor to modify the file junk.m.  For example, change '1' to '1A'.  Finally, run dbstatus to capture the segfault.

dbstatus
panic: Segmentation fault -- stopping myself...
attempting to save variables to 'octave-workspace'...
save to 'octave-workspace' complete
Segmentation fault

Rik <rik5>
Project Administrator

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #35828:  bug_44195.v3.txt added by lachlan (602B - text/plain)
file #35810:  bug_44195.v2.txt added by lachlan (1KiB - text/plain)
file #35809:  bug_44195.txt added by lachlan (897B - text/plain)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by lachlan (Updated the item)
  • -email is unavailable- added by lachlan ((wanting to integrate with his dbstop patch))
  • -email is unavailable- added by sebald (Posted a comment)
  • -email is unavailable- added by rik5 (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 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-01-17 rik5 StatusNone => Fixed
        Open/ClosedOpen => Closed
    2015-12-22 lachlan Attached File- => Added bug_44195.v3.txt, #35828
    2015-12-21 lachlan Attached File- => Added bug_44195.v2.txt, #35810
    2015-12-21 lachlan Attached File- => Added bug_44195.txt, #35809
    2015-12-09 lachlan Carbon-Copy- => Added lachlan

    Back to the top


    Powered by Savane 3.5