tags:

views:

439

answers:

1

UPDATE: This is a known bug - link requires a login to Mathworks to access it.

Summary of bug report

An instance of a MATLAB user-defined class saved to a MAT file using Version 7.6 (R2008a) might not load properly if one of its property values is an instance of a different MATLAB class.

Briefly, Mathworks reports that a previously saved top level custom object may be loaded incorrectly (as described below) and that the error occurs on the SAVE step. So, the data is corrupted inside the MAT file.

From my experience this seems to be intermittent. In one data analysis application I wrote out of 75 MAT files 37 were saved with this corruption :(

Be careful with user defined objects. I added the following test on save to make sure that the data is not corrupted

save('MAT_file_name.mat');

tmp=load('MAT_file_name.mat');
if ~isa(tmp.bb,'superClass')
    msgbox({'THE FILE WAS NOT SAVED PROPERLY', ...
            ' ', ...
            ['    MAT_file_name.mat',]})
end


Orginal Question

Here I am using MATLAB 2008a. This subtle bug is fixed in MATLAB-2009a. Anyway, the way my two classes are defined, the save/load cycle causes the variables of one class (superClass) to be loaded as variables of my second class (propClass).

Example MATLAB (r2008a) Session

>> bb=superClass;
>> whos
  Name      Size            Bytes  Class         Attributes
  bb        1x1                60  superClass              

>> save
>> clear
>> clear classes
>> load
>> whos
  Name      Size            Bytes  Class        Attributes
  bb        1x1                60  propClass

After loading matlab.mat, the variable bb has mysteriously changed from superClass to propClass

Class: superClass

This class needs to contain an array of type propClass and here is it's Naive definition

classdef superClass<handle
    properties(SetAccess=private)
        a = propClass.empty  % need to set this property as type propClass 
                             % otherwise the addProp method throws an error
        count=0;
    end
    methods
        function self=superClass
             %empty class definitionS
        end
        function addProp(self)
            p = propClass;
            self.count = self.count+1;
            self.a(self.count)=p;
        end
    end
end

Class: propClass

PropClass is a second class used by the super class. Its definition is not important for this bug.

Question

So, why is superClass being changed to propClass after the load operation in MATLAB-R2008a? Secondly, how can I change the definition of superClass to avoid this symptom?

Note

I ran into this symptom in a larger class I had written and narrowed down the source of the problem. I know it occurs in the MATLAB session described above but it seems that if I add an object to the property array in superClass then the problem disappears. So, if I call superClass.addProp before saving then the strange change from superClass to propClass doesn't occur.

+1  A: 

That's a strange problem! I haven't come across anything like that, but one thing you could try first is to move the initializations of the properties to the constructor:

classdef superClass < handle
    properties (SetAccess = private)
        a
        count
    end
    methods
        function self = superClass
            self.a = propClass.empty;
            self.count = 0;
        end
        function addProp(self)
            p = propClass;
            self.count = self.count+1;
            self.a(self.count) = p;
        end
    end
end

I'm not sure it will have any effect, but that's the only thing I can think of to try. Hope it helps! =)

gnovice
You hit the nail on the head. Moving the initialization into the constructor resolves the issue ;)
Azim
WOW! I was just taking a wild guess! I just figured if you changed the class definition so it conformed to the most common form it would behave properly. =)... Funny that they don't seem to mention it anywhere in the MATLAB documentation (no where I could find, anyway).
gnovice
I too was relieved that moving the initialization into the constructor solved the problem. It must be a bug in r2008a because the original code behaves properly in r2009a. A very situation strange indeed.
Azim

related questions