bugGNU Octave - Bugs: bug #40117, Corruption of symbol table when...

 
 

bug #40117: Corruption of symbol table when editing functions in private/ dirs

Submitted by:  Rik <rik5>
Submitted on:  Thu 26 Sep 2013 10:10:01 PM UTC  
 
Category:  Interpreter Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Ready For Test Assigned to:  None
Originator Name:  Open/Closed:  Open
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)

Thu 10 Sep 2020 08:58:44 PM UTC, comment #8: 

OK, I added a test and pushed the change on default:

http://hg.savannah.gnu.org/hgweb/octave/rev/68c792e54d19

John W. Eaton <jwe>
Project Administrator
Thu 10 Sep 2020 03:09:36 PM UTC, comment #7: 

@jwe: Thanks for the fix.  Obviously, I should have asked sooner rather than waiting 7 years.  I think this issue is encountered most by developers who are twiddling with files while coding and debugging within an Octave session.  And there is an easy workaround for ordinary users which is simply to quit the running Octave session and start a new one.  For those reasons, I would push it on the development branch rather than stable.

Rik <rik5>
Project Administrator
Thu 10 Sep 2020 03:50:21 AM UTC, comment #6: 

The problem was that the reloaded function was not marked as private, so when it was executed, it did not have access to other private functions in the same directory.  The attached patch fixes the problem for me.  It is relative to the current default sources, but should also apply to stable.  Where do you think this change should be made?

(file #49774)

John W. Eaton <jwe>
Project Administrator
Thu 10 Sep 2020 01:06:58 AM UTC, comment #5: 

I will take a look at this one.

John W. Eaton <jwe>
Project Administrator
Thu 10 Sep 2020 12:59:19 AM UTC, comment #4: 

Adding jwe to the CC list since he has worked a lot on cleaning up the symbol table implementation.  It seems silly to me that this bug is still here after 7 years.

Because paths have changed, here is re-drafted code to force the error.

demo ("quiver", 1)
## In another terminal window, execute 'touch scripts/plot/draw/private/__quiver__.m
demo ("quiver", 1)

Rik <rik5>
Project Administrator
Thu 26 Sep 2019 01:28:36 PM UTC, comment #3: 

I came across the same bug with this configuration:

.
├── A.m
└── private
    ├── B.m
    └── C.m

with files defined as:

function A ()
  disp ('A');
  B ();
endfunction

function B ()
  disp ('B');
  C ();
endfunction

function C ()
  disp ('C');
endfunction

An error occurs when B.m has his timestamp changed:

octave:1> A
A
B
C
octave:2> system ('touch A.m');
octave:3> A
A
B
C
octave:4> system ('touch private/C.m');
octave:5> A
A
B
C
octave:6> system ('touch private/B.m');
octave:7> A
A
B
error: 'C' undefined near line 3 column 3
error: called from
    B at line 3 column 3
    A at line 3 column 3

Guillaume <gyom>
Tue 22 Nov 2016 10:15:00 PM UTC, comment #2: 

This bug is still present in Octave 4.2.0.

(Fixing the mentioned bug #35067 doesn't seem to have helped.)

Hartmut <hardy>
Fri 27 Sep 2013 02:40:23 AM UTC, comment #1: 

Confirmed here. I wonder if this is related to your much older bug #35067 still present in the latest version.

Mike Miller <mtmiller>
Project Administrator
Thu 26 Sep 2013 10:10:01 PM UTC, original submission:  

Octave checks the timestamps of m-files.  If the timestamp has changed since the last time Octave compiled the function then the m-file is re-read and recompiled.

However, on a recent tip (55680de6a897, 9/26/13), I find that the symbol table becomes corrupted when the timestamp on an m-file in a private directory is changed.

Example

demo ("quiver", 1)
## In another terminal window, execute 'touch scripts/plot/private/__quiver__.m
demo ("quiver", 1)
quiver example 1:
clf;
[x,y] = meshgrid (1:2:20);
h = quiver (x,y, sin (2*pi*x/10), sin (2*pi*y/10));
set (h, 'maxheadsize', 0.33);

quiver example 1: failed
'__add_datasource__' undefined near line 152 column 14

I find that I can restore things if I execute

clear -f

to clear all functions from memory.

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 #49774:  private-fcn-patch.txt added by jwe (2KiB - 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 jwe (Posted a comment)
  • -email is unavailable- added by rik5
  • -email is unavailable- added by gyom (Posted a comment)
  • -email is unavailable- added by hardy (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 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-09-10 jwe StatusConfirmed => Ready For Test
    2020-09-10 jwe Attached File- => Added private-fcn-patch.txt, #49774
    2020-09-10 rik5 Carbon-Copy- => Added jwe
    2019-12-16 mtmiller Carbon-CopyRemoved 80942 => -
    2013-09-27 mtmiller StatusNone => Confirmed

    Back to the top


    Powered by Savane 3.5