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


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

Submitted by:  Arun Giridhar <arungiridhar>
Submitted on:  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

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)

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>
Project 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>
Project Administrator
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:

which results in

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>
Project 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>
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>
Mon 14 Jan 2013 09:08:17 PM UTC, comment #3:

Right, with second whos on new line
it works.

Michael Godfrey <godfrey>
Project 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>
Project Administrator
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>
Project 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:

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

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>


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

Attach Files:

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)

    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
    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.3