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.
|
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)
|
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)
|
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)
|
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
|
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.
|
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?
|
Fri 06 Feb 2015 06:04:26 PM UTC, comment #3:
I'm running Linux and confirmed this bug. I see
and consistent failure.
|
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.
|
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:
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.
|
Fri 06 Feb 2015 06:15:09 AM UTC, original submission:
Create a file junk.m with the lines
From within Octave, set two breakpoints with
Now use your editor to modify the file junk.m. For example, change '1' to '1A'. Finally, run dbstatus to capture the segfault.
|