Page MenuHome

Fix for ocean thread pool crash T71040
Needs ReviewPublic

Authored by Daniel Santana (dgsantana) on Wed, Oct 23, 1:44 PM.



After running lots of debug, I noticed that the simulate_ocean_modifier gets call multiples times, when it should probably only called when the modifier gets evaluated.
The cause for the crash seems that 2 or threads try to access the modifier that, I couldn't pin point the exact place where the 2 or more pools are created at the same, but this is visible when a long ocean operation occurs.

This patch removes two calls, one on init and another on copy. There are still one that can't be removed easily on set_height_normalize_factor.
Also move some of the variables on the simulation to be inside the mutex protection, and that seems to solve the crash.

Diff Detail

rB Blender

Event Timeline

Doing simulation call n init and copy indeed seems weird.
But wondering whether it's a deeper design/threading issue burried somewhere deeper?


This seems to be a non-funcitonal change.


If there is no need to simulate just remove the call. Having dead code is not helpful.

Could extend the comment why it is not needed though.


Same as above.


This change is the one that "fixes" the problem. It seems there are multiple threads running this function, which in turn cause a sharing violation. Just making this 2 assign happen inside the lock avoids the crash. But the inner problem persists, which is why for the at least Ocean there are if I recall 4 calls to this function just adding the modifier. Even moving an object with the Ocean modifier also triggers this calls.

Removed the comment code as requested.

Daniel Santana (dgsantana) marked 2 inline comments as done.Mon, Oct 28, 10:32 AM

Where exactly the threading issue happening?


This sharing violation occurs on trying to free the task in task_free (task.c line 454).
It's very easy to check. Just add the ocean on the default cube and set the resolution to 32, or higher something that takes some time to calculate.

I don't have the fftw sources here in windows and need to boot into Linux to check this. I will check later.

Ok I did some digging and the problem is the threading in fftw and blender. Basically the fftw plans should be protected by a lock/mutex, and before the patch they aren't, they are outside the mutex (they live in Ocean struct. So this fix is indeed the correct way to make both multi-threading work.

Daniel Santana (dgsantana) marked an inline comment as done.Tue, Oct 29, 1:38 PM