Discover MakerZone

MATLAB and Simulink resources for Arduino, LEGO, and Raspberry Pi

Learn more

Discover what MATLAB® can do for your career.

Opportunities for recent engineering grads.

Apply Today

To resolve issues starting MATLAB on Mac OS X 10.10 (Yosemite) visit: http://www.mathworks.com/matlabcentral/answers/159016

Unable to clear classes

Asked by Jim Hokanson on 23 Oct 2012

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
Jim Hokanson

Products

No products are associated with this question.

6 Answers

Answer by Jim Hokanson on 27 Apr 2013
Accepted answer

This is a bug:

893538

It has been fixed in 2013a

0 Comments

Jim Hokanson
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:

Bug report: 857319

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.

Sean de Wolski
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

Malcolm Lidierth
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?

Matt J
Answer by Daniel on 25 Oct 2012

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

0 Comments

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

Malcolm Lidierth on 9 Nov 2012

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.

Matt J

Contact us