Has save() bug been fixed?

I have a user-defined object that is failing to save in R2024b,

>> save testsave mgr

Warning: Variable 'mgr' was not saved. For variables larger than 2GB use MAT-file version 7.3 or later.

It is true that mgr is greater than 2GB. However, it belongs to a class with a saveobj() defined, which greatly compresses the size of the saved object. But the saveobj() method is never reached. The save() operation rejects the variable based on its original size, and never calls saveobj().

I think this has got to be a bug. Does anyone know if it has been fixed in more recent Matlab versions?

[Stephen23]

"The save() operation rejects the variable based on its original size"

Which is exactly what the SAVE documentation refers to: the variable size.

"I think this has got to be a bug."

Why? The SAVE documentation clearly documents the limits of MAT files according to the variable size, not in terms of any (possibly compressed) resulting file size. It is odd to describe something working exactly as documented to be a "bug".

[Matt J]

Which is exactly what the SAVE documentation refers to: the variable size.

Is that what the documentation refers to? It could be referring to the variable that is passed as input to save() or it could be the variable that actually gets written to the file (i.e. the output of saveobj). The latter would make the most sense, because otherwise one of the primary use cases of saveobj is undermined.

[dpb]

save defines the input variables as "Names of variables to save..." from which I think it's clear it's intended as applying to the existing object in memory.

That the support response reflects unintended behavior in prematurely exiting before calling a user-defined saveobj function with other than -v7.3 reinforces the conclusion I drew that it was simply an overlooked edge case that a custom function could perform compression behind SAVE's back.

ADDENDUM

Of course, the user-supplied function then will have to handle it's own case if it turns out compression also doesn't manage to get under the 2GB limit to write the variable out in -V7

Answer 1

[dpb]

I'd doubt Mathworks thought of that scenario as being a bug.

While it's clumsy, a search of the bugs database for the keyword SAVE didn't uncover anything matching this description for release from R2024b and newer and a search for saveobj had zero hits in R2024b.

My thinking is this is not in the bugs database and would have to be reported as such to make the list.

[Matt J]

Does anyone know if it has been fixed in more recent Matlab versions?

I didn't think the R2026z online run engine would let me allocate 2GB, but apparently it did! But it clearly hasn't been fixed :-(

mgr=myclass; mgr.X=rand(16385,16385);

save testfile mgr

Warning: Variable "mgr" was not saved. For variables larger than 2GB use MAT-file version 7.3 or later.

save testfile mgr -v7.3

saveobj called

[dpb]

It would have to be considered as an actual bug first before it would/could be "fixed"... <grin>

While this shows the class saveobj function was called, was it successful in creating a workable .mat file and was it created as -v7.3 or did your custom routine override?

[Steven Lord]

Have you reported this to the Support staff as an undesirable behavior in save? [If the documentation describes the behavior as expected this isn't technically a bug, but that doesn't necessarily mean the behavior is what users expect or want.]

If you have reported it in the past, you could contact Support to ask them to nominate this issue as a Bug Report. Or if you report it now, you can ask Support to report it to the development staff and nominate it for a Bug Report. Then if it gets published as a Bug Report, you can follow that report and be notified when it changes (usually when it's reported fixed in a new Update or general release.)

[dpb]

I can't find anything in the doc that accounts for anything other than the observed behavior of providing the warning message that the variable >2GB wasn't saved.

It seems quite reasonable that SAVE just looks at the footprint of the variable in the workspace and throws up its hands as a behavior; simply nobody ever thought about there being a customized saveobj in a user-written class that compresses on its own and so can get the object in question under the 2GB threshold.

It also seems like an enhancement request or bug report is in order in order to accomodate the case, certainly..

[Matt J]

From Tech Support:

"I investigated the issue and was able to reproduce the behavior that you described. This is unexpected behavior, and I have forwarded this issue to our development team who will investigate a fix for this issue. You will be notified via email if a fix is included in a future MATLAB release."