Unable to clear classes

At times I am unable to clear classes in Matlab without restarting the program. This seems to be related to errors being thrown in the class. In other words, following an error I might make a change to the class and then call "clear classes" to reset everything. Also, since 95% of the time I am working with handle classes, this may be handle class related.

Some issues I have run across that I know are not currently the problem are: 1) storage of the class in a figure which is still open 2) the default value of a property being a class

Thanks, Jim

[Matt J]

Ok, but what are the symptoms of the problem? What evidence do you see that the classes aren't being cleared?

[Jim Hokanson]

To be more specific, Matlab will throw a warning message to the effect of: Warning, changes have been made to the class [class name] but changes cannot be applied because instances of the class still exist

As the warning implies, this occurs whenever working with an instance of the class after changes have been made to it. The code also behaves like the old version of the class, it doesn't just throw the warning and then use the new version of the class.

Also, as a little more info, the specific instance that prompted me to ask this question was an error in the constructor (which I then subsequently fixed). I don't know if that is also what has happened in the many other times that I've run into this problem or not. Like I mentioned, I've come across at least two other instances (see original question) where I could eventually identify and remedy the problem.

[Jim Hokanson]

Also, perhaps to answer your question a bit more directly, new properties or methods, as well as changed attributes are not properly recognized when this warning appears. I will get an error referring to a non-existent method even though the method exists (but was defined after an instance of the class existed).

[Matt J]

What MATLAB version are you running?

[Jim Hokanson]

Right now 2012b, win7 64 bit, but I'm pretty sure I've seen this behavior in previous versions as well.

[Matt J]

And once you issue "clear classes", no variables remain in your workspace, and you have no figures or GUIs open?

[Jim Hokanson]

Correct.

[Matt J]

Just in case it matters, I noticed a very similar phenomenon and provided an example that reproduces it in R2009b here. The other posters in that Newsgroup thread claimed that the problem was also reproducible via the same example in R2010b.

However, I have only retested it recently on R2012a (win7 64-bit) and I am not seeing it anymore, so I guess it doesn't apply to you. It might be worthwhile trying it though.

[Matt J]

Another question. What exactly is the output of "clear classes", if any? You've described an inability to use the classes after making changes, but does "clear classes" warn you that the classes are unclearable?

[Jim Hokanson]

Matt, regarding your example, this problem exists in 2011a but not 2012b. Will update the next time I see this problem regarding the output and clear all.

[Matt J]

Does "clear classes" itself produce warnings?

[Jim Hokanson]

I have confirmed with TMW that the example I provided below is a bug. Unfortunately I have not yet received a bug ID. One of the problems I identified (there may be more) is when children hold onto a reference of the parent object, and the parent holds onto a reference of the children. This only occurs when there are more than 2 children.

A workaround:

N = 4 %number of children
for iChild = 1:N
  tempChildren(iChild) = child_class(parent_class);
end

parent_class.children = tempChildren;

%NOTE: In the child we have something like

function obj = child_class(parent_obj)
obj.parent = parent_obj;

The bug would occur in this case below: These are both handles clases

parent_class.children = child_class(parent_class,4)

function obj = child_class(parent_obj,N)
if nargin == 0
   return
end

obj(N) = child_class;
for iObj = 1:N
   obj(iObj) = child_class;
   obj.parent = parent_obj;
end

Answer 1

[Jim Hokanson]

This is a bug:

893538

It has been fixed in 2013a

Answer 2

[Sean de Wolski]

Hi Jim,

Are you saving the objects to or loading from a *.mat file? If so please see:

Bug report: 857319

This bug report doesn't highlight the workaround though, which is to not store the *.mat files with -v7.3 formatting.

[Jim Hokanson]

I am not, but this is good to know. Thanks.

[Sean de Wolski]

Do you have a simple test class that can reproduce this? If so, could you post it here or email it to me?

[Jim Hokanson]

I finally had a reproducible instance of this. I feel like this may be one of many ways of causing this behavior. To answer Matt J above, I don't know if clear classes would always throw warnings or not.

Here's the code:

classdef class_1 < handle
    properties
       temp
    end
    methods
        function obj = class_1(N)
           obj.temp = class_1.class_2(obj,N);  
        end
    end
end

classdef class_2
    properties
        parent
    end
    methods
        function obj = class_2(parent,N)
           if nargin == 0
               return
           end
           obj(N) = class_1.class_2;
           for iObj = 1:N
              obj(iObj).parent = parent; 
           end
        end
    end
end

On disk this is laid out as:

@class_1

+class_1/@class_2

NOTE: Surprisingly the N seems to be important here. An N of 1 or 2 doesn't cause this, but an N of 3 or more does. It may be possible to "simplify" this further, but I figured it gives you a place to start.

This is on 2012b 64bit Win 7

[Matt J]

This code doesn't run. In particular

obj.temp = class_1.class_2(obj,N);

makes it complain that class_2 is a non-existant property of class_1.

Also, the following statement is unclear

On disk this is laid out as: @class_1 +class_1/@class_2

Is this all one single directory name or 2 separate ones? Do you mean that class_1.m is sitting in a directory called @class_1/ and class2.m is sitting in a package directory called +class1/@class_2/ ?

[Jim Hokanson]

Oops, yeah, sorry about that. I'm not even sure if that is necessary but it is how I discovered it (with a similar package setup). class_2 should be in a class_1 package. Both classes were in @ folders.

Going one level up you might have:

myfolder/@class_1/

myfolder/+class_1/@class_2/

[Matt J]

OK, but finish your example. You've so far only specified class definitions. What sequence of class construction commands would we run to reproduce the problem?

[Matt J]

Never mind, I was able to reproduce the problem with

class_1(10);
clear classes;

This was even without the directory structure you specified, and it was in R2012a. Also, "clear classes" always gives me a warning.

Answer 3

[Malcolm Lidierth]

Object references can leak via userdata or appdata, callbacks, the variable editor etc. Try closing all figures - but probably close the variable editor first.

With handle classes I have taken to maintaing a list in the figure appdata area maintained by calling a common superclass method from the constructors, and adding a DeleteFcn callback that calls a static superclass method to delete any remaining valid handle objects when a figure closes. A bit of a pain but it seems to work.

Answer 4

[Matt J]

Just a thought. Try doing REHASH. Then clear classes again.

[Jim Hokanson]

No luck.

[Matt J]

what about my latest comments/questions above?

Answer 5

[Daniel Shub]

Two related, but not duplicate, questions are

http://www.mathworks.com/matlabcentral/answers/48088-inability-to-clear-object-definition-nonfunctional-clear-classes

http://www.mathworks.com/matlabcentral/answers/33905

There was also a related question sometime in the past few months where it eventually seemed like the problem was a bug (the problem disappeared in some release) It involved two classes calling each other. I can no longer find the question (which isn't surprising give the search capabilities of Answers).

Answer 6

[Matt J]

Based on your example with class_1 and class_2, I think the problem is related to the fact that you are creating handle objects which contain shared copies of themselves (the temp property is passed copies of obj itself in the constructor). I can't explain why the problem occurs only for N>2, however, it's easy to see that you create a chicken-and-egg situation when MATLAB tries to delete an object of class_1: before MATLAB can delete an object of class_1, it must first delete all the data in the properties that it contains. However, the properties of the class_1 object contain the object itself!

Is there any way you can settle for unshared copies of class_1 in temp?

[Malcolm Lidierth]

Or clear the cross-references in a custom delete method.

[Matt J]

Don't think that will work. If you insert delete() methods into both class_1 and class_2 in the OP's example, you will see that none of the delete methods are ever called. It is as if MATLAB recognizes the chicken-and-egg situation in advance and just declines attempting to delete.

[Jim Hokanson]

Matt,

Point noted, but this seems like a bug to me. This setup is very much like a tree class, in which it is desirable for parents to know about their children and children about their parents. I was hoping in the mean time that there might be some method which can force clear classes. I haven't considered the consequences of such a function and if this bug didn't exist it wouldn't necessarily be needed. I think I'll go ahead and submit a bug report.

Thanks for checking with 2012a and the non-package version.

Jim

[Matt J]

Jim,

I agree that it's a bug in the sense that the class_1 constructor should return an error when you try to do what you're doing, as opposed to MATLAB refusing to clear the memory later.

I disagree though that this is a simple case of a tree class, because in your case the tree branches never terminate. It's like the children went back in time and fathered themselves, a la Hitchhiker's Guide to the Galaxy. Your attempt to delete the parent can only generate an infinite recursion of child deletes, which MATLAB has to bail out of in some way.

[Malcolm Lidierth]

Does subclassing hgsetget instead of handle help? Standard handle graphics always have a parent/child hierarchy.

Do the classes need to be in the same package?

I do not recall recognizing this behaviour in my own classes (but all use hgsetget and never use packages - in MATLAB anyway).

However, I do have isvalid tests in the delete methods on the instance being deleted because function delete(obj) sometimes gets a valid and sometimes an invalid obj. I think this problem may (??) be related - at what stage during deletion does isvalid return false when there are leaks, and what order does MATLAB delete a circular reference. obj.delete() can get called even when obj.isvalid() returns false. Is it the MATLAB delete equivalent of referencing "this" in a constructor in e.g. Java.

Answer 7

[Chris Wiak]

I have the same problem in Matlab 2015b. 'clear classes' throws a warning. Any thoughts on this one?

Answer 8

[Fuad Numan]

ClassStore.Class1=struct();

This will clear a specific variable (Class1) from the main Class (ClassStore).