bugGNU Octave - Bugs: bug #38086, "clear all" does not...

 
 

bug #38086: "clear all" does not clear variables defined on command line?

Submitter:  Arun Giridhar <arungiridhar>
Submitted:  Mon 14 Jan 2013 07:49:02 PM UTC
   
 
Category:  Interpreter Severity:  2 - Minor
Priority:  1 - Later Item Group:  Inaccurate Result
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sat 25 Jan 2014 07:44:14 AM UTC, comment #8: 

This seems to have been fixed somewhere in the past year.  Closing report.

Rik <rik5>
Group administrator
Fri 24 Jan 2014 08:39:57 PM UTC, comment #7: 

I cannot reproduce this bug with Octave 3.8.0. Can anyone who confirmed this behavior before confirm that it is now working correctly?

Mike Miller <mtmiller>
Group Member
Thu 21 Feb 2013 12:02:45 AM UTC, comment #6: 

It's not a race condition, but it is odd.  I've downgraded the severity because this isn't really damaging to anyone.

I believe the issue is that the single line, even with semicolons, is being evaluated in a single temporary working space.

For example, try this code:


clear all; clc; i = 20; j = 10; whos; clear all; whos ; k = 30; whos; clear all; whos


which results in


Variables in the current scope:

   Attr Name        Size                     Bytes  Class
   ==== ====        ====                     =====  =====
        i           1x1                          8  double
        j           1x1                          8  double
        k           0x0                          0  unknown

Total is 2 elements using 16 bytes

Variables in the current scope:

   Attr Name        Size                     Bytes  Class
   ==== ====        ====                     =====  =====
        i           0x0                          0  unknown
        j           0x0                          0  unknown
        k           0x0                          0  unknown

Total is 0 elements using 0 bytes

Variables in the current scope:

   Attr Name        Size                     Bytes  Class
   ==== ====        ====                     =====  =====
        i           0x0                          0  unknown
        j           0x0                          0  unknown
        k           1x1                          8  double

Total is 1 element using 8 bytes

Variables in the current scope:

   Attr Name        Size                     Bytes  Class
   ==== ====        ====                     =====  =====
        i           0x0                          0  unknown
        j           0x0                          0  unknown
        k           0x0                          0  unknown

Total is 0 elements using 0 bytes


What is interesting is that k has not even been defined for the first execution of 'whos' and yet it is still showing up in the symbol table.

Rik <rik5>
Group administrator
Mon 14 Jan 2013 10:36:38 PM UTC, comment #5: 

Now I'm thinking it's not a question of giving time between clear and whos. I tried introducing pause statements between the two with 1-second delays, and that doesn't resolve the behavior, but putting them on separate lines does. Some code triggered only on end-of-line or end-of-file but not semicolons perhaps?

Either way, feel free to downgrade its priority.

Arun Giridhar <arungiridhar>
Group Member
Mon 14 Jan 2013 10:20:34 PM UTC, comment #4: 

That's an interesting race condition! To add more information, leaving everything in one line still works properly from the file; I suppose the file-reading introduces enough delay to break the race.

As this race would show up only if whos is called immediately after clear, feel free to downgrade its priority.

Arun Giridhar <arungiridhar>
Group Member
Mon 14 Jan 2013 09:08:17 PM UTC, comment #3: 

Right, with second whos on new line
it works.

Michael Godfrey <godfrey>
Group Member
Mon 14 Jan 2013 08:45:37 PM UTC, comment #2: 

This looks like a race condition?

The problem isn't whether it's from an m-file or not, but whether you give it enough time to finish or not.

Try running the second whos in a separate line, for example.

Jordi GutiƩrrez Hermoso <jordigh>
Group Member
Mon 14 Jan 2013 07:54:13 PM UTC, comment #1: 

I see same behavior of Fedora 17.

Looks like a bug.

Michael Godfrey <godfrey>
Group Member
Mon 14 Jan 2013 07:49:02 PM UTC, original submission:  

I noticed this odd behavior crop up recently with "clear all" and "whos". It does not break any of my code, but I thought I should report it if it is a symptom of something deeper.

Try running the following from the octave command prompt:


clear all; clc; i = 20; j = 10; k = 50; foo = 23; whos; clear all; whos


On my system (Ubuntu 12.04.1 64 bit on x86_64) the output is:


Variables in the current scope:

   Attr Name        Size                     Bytes  Class
   ==== ====        ====                     =====  =====
        foo         1x1                          8  double
        i           1x1                          8  double
        j           1x1                          8  double
        k           1x1                          8  double

Total is 4 elements using 32 bytes

Variables in the current scope:

   Attr Name        Size                     Bytes  Class
   ==== ====        ====                     =====  =====
        foo         0x0                          0  unknown
        i           0x0                          0  unknown
        j           0x0                          0  unknown
        k           0x0                          0  unknown

Total is 0 elements using 0 bytes


HOWEVER: creating a .m script file with the above line of code and then calling that script makes "clear all" work properly, and the second "whos" does not list any variables in that case.

Could someone please verify this behavior?

Arun Giridhar <arungiridhar>
Group Member

 

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

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by jordigh (Posted a comment)
  • -email is unavailable- added by godfrey (Posted a comment)
  • -email is unavailable- added by arungiridhar (Submitted the item)
  •  

    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 group members can vote.

     

    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2014-01-25 rik5 StatusNeed Info Fixed
        Open/ClosedOpen Closed
    2014-01-24 mtmiller StatusConfirmed Need Info
    2013-02-21 rik5 Severity3 - Normal 2 - Minor
        Priority5 - Normal 1 - Later
    2013-01-14 jordigh StatusNone Confirmed

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code