MATLAB Answers

4

Unable to clear classes

Asked by Jim Hokanson on 23 Oct 2012
Latest activity Answered by Fuad Numan on 4 Feb 2016
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

  12 Comments

Jim Hokanson on 24 Oct 2012
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
on 24 Oct 2012
Does "clear classes" itself produce warnings?
Jim Hokanson on 27 Nov 2012
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

Sign in to comment.

8 Answers

Answer by Jim Hokanson on 27 Apr 2013
 Accepted Answer

This is a bug:
It has been fixed in 2013a

  0 Comments

Sign in to comment.


Sean de Wolski
Answer by Sean de Wolski
on 24 Oct 2012

Hi Jim,
Are you saving the objects to or loading from a *.mat file? If so please see:
This bug report doesn't highlight the workaround though, which is to not store the *.mat files with -v7.3 formatting.

  7 Comments

Jim Hokanson on 7 Nov 2012
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
on 7 Nov 2012
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
on 7 Nov 2012
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.

Sign in to comment.


Answer by Malcolm Lidierth on 7 Nov 2012

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.

  0 Comments

Sign in to comment.


Matt J
Answer by Matt J
on 24 Oct 2012

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

  2 Comments

Jim Hokanson on 24 Oct 2012
No luck.
Matt J
on 24 Oct 2012
what about my latest comments/questions above?

Sign in to comment.


Daniel Shub
Answer by Daniel Shub
on 25 Oct 2012

Two related, but not duplicate, questions are
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).

  0 Comments

Sign in to comment.


Matt J
Answer by Matt J
on 7 Nov 2012
Edited by Matt J
on 8 Nov 2012

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?

  5 Comments

Jim Hokanson on 9 Nov 2012
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
on 9 Nov 2012
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.
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.

Sign in to comment.


Answer by Chris Wiak on 4 Feb 2016

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

  0 Comments

Sign in to comment.


Answer by Fuad Numan on 4 Feb 2016

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

  0 Comments

Sign in to comment.