Matlab segmentation fault when iterating vector assignment

Question

I've been vectorizing some matlab code I'd previously written, and during this process matlab started crashing due to segmentation faults. I narrowed the problem down to a single type of computation: assigning to multiple struct properties.

For example, even self assignment of this form eventually causes a seg fault when executed several thousand times:

[my_class_instance.my_struct_vector.my_property] = my_class_instance.my_struct_vector.my_property;

I initially assumed this must be a memory leak of some sort, so tried printing out java's free memory after every iteration, but this remained fairly constant.

So yeah, completely at a loss now as to why this breaks :-/

UPDATE: the following changes fixes the seg faulting:

temp = [my_class_instance.my_struct_vector];

[temp.my_property] = temp.my_property;

[my_class_instance.my_struct_vector] = temp;

The question is now why this would fix anything. Something about repeated accessing a handle class rather than a struct list perhaps?

UPDATE 2: THE PLOT THICKENS

I've finally replicated the problem and the work around using a dummy program simple enough to post here:

a simple class:

classdef test_class
    properties
        test_prop
    end
end

And a program that makes a bunch of vector assignments with the class, and will always crash.

test_instance = test_class();
test_instance.test_prop = struct('test_field',{1 1});
for i=1:10000

    [test_instance.test_prop.test_field] = test_instance.test_prop.test_field;
end

UPDATE 3: THE PLOT THINS

Turns out I found a bug. According to Matlab tech support, repeated vector assignment of class properties simply won't work in R2011a (and presumably in earlier version). He told me it works fine in R2012a, and then mentioned the same workaround I discovered: use a temporary variable.

So yeah...

pretty sure this question ends with that support ticket, but if any daring individuals want to take a shot as to WHY this bug exists at all, I'd definitely still be interested in such an answer. (learning is fun!)

Refusal

Can't help you here...I have R2010b on Linux 64 bit, and it works fine there. Do you get a memory dump or similar? – Latitudinarian

Just attached the memory dump -- I'm having trouble replicating it outside of my large program though :-/ It is just that one line though; I comment it out and the code runs fine. What sort of odd side effects might cause something like this? – Refusal

Awesome, you found a MATLAB bug. Seems like this is repeatable enough to report to MathWorks... – Chrystal

Yup, I suggest you submit the dump + code to produce it to them via mathworks.com/support/contact_us There's nothing any of us can do here -- it seems like a genuine bug specific to 2011a/Win64 – Latitudinarian

Just replicated it on R2011A Mac 64 bit. Sending out the support request now; though answers here would be greatly appreciated if anyone has anymore thoughts. Thanks for all of the help! – Refusal

Added a link to the dropbox where u can download the code and test it for yourselves -- its just 1 .mat file and 1 .m script. The script loads the 1 variable from the .mat file and trying to do the kind of computation I mentioned 10000 times (should only take a few seconds). Running this script nearly always crashes my matlab. – Refusal

@Refusal My MATLAB is unable to instantiate the object game. I think I would also need the objects .m file to get it working. – Finitude

I can confirm what denahiro said, we can't load the .mat file without your top_lane_game class – Backstairs

Sorry about that! I added the require class definition files to the folder -- the link should have all of the files needed now – Refusal

@Finitude try copying the code I just pasted into the question. Its concise, yet still causes the crashing problem. – Refusal

Answer 1

By far the most likely cause is that the operation is internally using self-modifying code. The problem with this is that modern processors have CPU caches, so if you change code in memory, but the code has already been committed to a cache, it will generate a seg fault.

The reason why it is random is because it depends on whether the modified code is in the cache at the time of modification and other factors.

To avoid this the programmer has to be sure to have the code flush the cache before doing a self-modification.

Overline

You've successfully removed one more specter from the pantheon of programming ghouls. Thanks and congrats! – Refusal