Paths

Table of Contentst

Fix for ocean thread pool crash T71040
AbandonedPublic
Actions

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

Details

Reviewers

Philipp Oeser (lichtwerk)
Campbell Barton (campbellbarton)

Group Reviewers

Modifiers

Maniphest Tasks

T71040: Ocean modifier crashes blender.

Summary

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

Repository: rB Blender

Event Timeline

Daniel Santana (dgsantana) created this revision.Oct 23 2019, 1:44 PM

Daniel Santana (dgsantana) added a task: T71040: Ocean modifier crashes blender..Oct 23 2019, 1:50 PM

Daniel Santana (dgsantana) added a subscriber: Philipp Oeser (lichtwerk).

Daniel Santana (dgsantana) added a reviewer: Philipp Oeser (lichtwerk).Oct 23 2019, 1:57 PM

Daniel Santana (dgsantana) removed a subscriber: Philipp Oeser (lichtwerk).

Daniel Santana (dgsantana) added a reviewer: Campbell Barton (campbellbarton).Oct 23 2019, 3:00 PM

Daniel Santana (dgsantana) added a reviewer: Modifiers.Oct 27 2019, 9:07 PM

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

source/blender/blenkernel/intern/ocean.c
763	This seems to be a non-funcitonal change.
source/blender/modifiers/intern/MOD_ocean.c
111–112	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.
151–152	Same as above.

Daniel Santana (dgsantana) added inline comments.Oct 28 2019, 10:29 AM

source/blender/blenkernel/intern/ocean.c
763	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.Oct 28 2019, 10:32 AM

Sergey Sharybin (sergey) added inline comments.Oct 28 2019, 10:52 AM

source/blender/blenkernel/intern/ocean.c
763	Where exactly the threading issue happening?

Daniel Santana (dgsantana) added inline comments.Oct 28 2019, 11:07 AM

source/blender/blenkernel/intern/ocean.c
763	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.Oct 29 2019, 1:38 PM

This should be ready. Just to remind, the problem was the threading in fftw that caused problems with the threading in Blender, the lock should happen before any changes on osd.

If the issue is in FFTW then i would expect locking to happen closer to it.

The lock should happen before any changes on osd

In this specific case the osd variable is local and is not shared across threads. The values which are being assigned to structure members do not change in the function (as in, Ocean pointer stays the same, t, scale and chop_amount stay the same). So moving lock around would not change values osd holds.

To me it sounds that by moving lock around you are affecting on threading scheduler, which just happens to masquerade the issue.

This sharing violation occurs on trying to free the task in task_free (task.c line 454).

That code should not be affected by any of the code outside of task.c. So either you see an induced issue there (some bigger memory corruption somewhere else, which just got caught in task scheduler) or there is threading issue in task scheduler itself *shrug*

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.

Unfortunately, no. Such threading issues are always hard to reproduce on someone's else machine. I didn't manage to reproduce the issue so far.

What I noticed while debugging that sometimes fftw threads were still working when the call to release the bli_task was called, creating a sharing violation. On Windows, it *was* easily reproduced by setting a high value on the ocean resolution, but on the lastest master I can no longer reproduce the error :). So the problem probably got hidden by a recent change.
Regarding the mutex outside the local variable definition, well that as what I understood from reading FFTW documentation, but maybe I miss interpreted.

@Sergey Sharybin (sergey), should I scrap this diff, so that it doesn't look like it was abandoned, since at least with the lastest master doesn't make sense keeping it?

@Daniel Santana (dgsantana), well, there are two aspects here.

First one is that the simulation call indeed looks suspicious. This is something which should only be happening when modifier is evaluated from dependency graph. If someone else (@Campbell Barton (campbellbarton) or @Bastien Montagne (mont29)) can have a second look to check nothing obviously is breaking we should put that part into Blender.

Second one is related on the threading conflict you've mentioned. My feeling is that moving lock in the current patch just masquerades the real issue.
Can you share some full stacktrace (of all threads) at the moment when crash happens? (not a core dump, but the stacktrace which is more human readable :))

I agree on the calls, simply creating the modifier, generate multiple calls to the simulate. After removing them I haven't noticed any problem, but of course is better to check.
This, is a hit and miss, case, you are right this is hidding some other problem, since I can't always get a crash.

Here is a full stack trace (Windows 10, i7 7820X, 64Gb, Geforce 2080Super):
Stack at exception site:

 	blender.exe!fftw_khc2c_register()	Unknown
 	blender.exe!fftw_null_awake()	Unknown
 	blender.exe!fftw_dft_rank_geq2_register()	Unknown
 	blender.exe!fftw_rdft2_buffered_register()	Unknown
 	blender.exe!fftw_rdft2_solve()	Unknown
 	blender.exe!fftw_execute()	Unknown
>	blender.exe!ocean_compute_displacement_y(TaskPool * pool, void * UNUSED_taskdata, int UNUSED_threadid) Line 551	C
 	blender.exe!task_scheduler_thread_run(void * thread_p) Line 451	C

Threads with call stack:

Not Flagged		37432	0	Worker Thread	main	blender.exe!mul_complex_c
 	 	 	 	 	 	blender.exe!mul_complex_c(double * res, double * cmpl1, double * cmpl2) Line 250
 	 	 	 	 	 	blender.exe!ocean_compute_displacement_z(TaskPool * pool, void * UNUSED_taskdata, int UNUSED_threadid) Line 604
 	 	 	 	 	 	blender.exe!BLI_task_pool_work_and_wait(TaskPool * pool) Line 938
 	 	 	 	 	 	blender.exe!BKE_ocean_simulate(Ocean * o, float t, float scale, float chop_amount) Line 810
 	 	 	 	 	 	blender.exe!set_height_normalize_factor(Ocean * oc) Line 830
 	 	 	 	 	 	blender.exe!BKE_ocean_init(Ocean * o, int M, int N, float Lx, float Lz, float V, float l, float A, float w, float damp, float alignment, float depth, float time, short do_height_field, short do_chop, short do_normals, short do_jacobian, int seed) Line 1066
 	 	 	 	 	 	blender.exe!BKE_ocean_init_from_modifier(Ocean * ocean, const OceanModifierData * omd) Line 899
 	 	 	 	 	 	blender.exe!copyData(const ModifierData * md, ModifierData * target, const int flag) Line 148
 	 	 	 	 	 	blender.exe!modifier_copyData_ex(ModifierData * md, ModifierData * target, const int flag) Line 350
 	 	 	 	 	 	blender.exe!BKE_object_copy_data(Main * bmain, Object * ob_dst, const Object * ob_src, const int flag) Line 1385
 	 	 	 	 	 	blender.exe!BKE_id_copy_ex(Main * bmain, const ID * id, ID * * r_newid, const int flag) Line 671
 	 	 	 	 	 	blender.exe!DEG::`anonymous namespace'::id_copy_inplace_no_main(const ID * id, ID * newid) Line 288
 	 	 	 	 	 	blender.exe!DEG::deg_expand_copy_on_write_datablock(const DEG::Depsgraph * depsgraph, const DEG::IDNode * id_node, DEG::DepsgraphNodeBuilder * node_builder, bool create_placeholders) Line 908
 	 	 	 	 	 	blender.exe!DEG::deg_update_copy_on_write_datablock(const DEG::Depsgraph * depsgraph, const DEG::IDNode * id_node) Line 1499
 	 	 	 	 	 	blender.exe!DEG::deg_evaluate_copy_on_write(Depsgraph * graph, const DEG::IDNode * id_node) Line 1634
 	 	 	 	 	 	[External Code]
 	 	 	 	 	 	blender.exe!DEG::deg_task_run_func(TaskPool * pool, void * taskdata, int thread_id) Line 89
 	 	 	 	 	 	blender.exe!handle_local_queue(TaskThreadLocalStorage * tls, const int thread_id) Line 421
 	 	 	 	 	 	blender.exe!BLI_task_pool_work_and_wait(TaskPool * pool) Line 947
 	 	 	 	 	 	blender.exe!BLI_task_pool_work_wait_and_reset(TaskPool * pool) Line 969
 	 	 	 	 	 	blender.exe!DEG::deg_evaluate_on_refresh(DEG::Depsgraph * graph) Line 286
 	 	 	 	 	 	blender.exe!DEG_evaluate_on_refresh(Main * bmain, Depsgraph * graph) Line 65
 	 	 	 	 	 	blender.exe!scene_graph_update_tagged(Depsgraph * depsgraph, Main * bmain, bool only_if_tagged) Line 1350
 	 	 	 	 	 	blender.exe!BKE_scene_graph_update_tagged(Depsgraph * depsgraph, Main * bmain) Line 1375
 	 	 	 	 	 	blender.exe!wm_event_do_depsgraph(bContext * C, bool is_after_open_file) Line 371
 	 	 	 	 	 	blender.exe!wm_event_do_refresh_wm_and_depsgraph(bContext * C) Line 398
 	 	 	 	 	 	blender.exe!wm_event_do_notifiers(bContext * C) Line 564
 	 	 	 	 	 	blender.exe!WM_main(bContext * C) Line 423
 	 	 	 	 	 	blender.exe!main(int argc, const unsigned char * * UNUSED_argv_c) Line 498
 	 	 	 	 	 	[External Code]

Not Flagged		5168	0	Worker Thread	ntdll.dll thread	ntdll.dll!00007ff8248ffa54
 	 	 	 	 	 	[External Code]

Not Flagged		31344	0	Worker Thread	ntdll.dll thread	ntdll.dll!00007ff8248ffa54
 	 	 	 	 	 	[External Code]

Not Flagged		26188	0	Worker Thread	ucrtbased.dll thread	blender.exe!IlmThread::Semaphore::wait
 	 	 	 	 	 	[External Code]

Not Flagged		12220	0	Worker Thread	ucrtbased.dll thread	blender.exe!IlmThread::Semaphore::wait
 	 	 	 	 	 	[External Code]

Not Flagged		28072	0	Worker Thread	ucrtbased.dll thread	blender.exe!IlmThread::Semaphore::wait
 	 	 	 	 	 	[External Code]

Not Flagged		19664	0	Worker Thread	ucrtbased.dll thread	blender.exe!IlmThread::Semaphore::wait
 	 	 	 	 	 	[External Code]

Not Flagged		12540	0	Worker Thread	ucrtbased.dll thread	blender.exe!IlmThread::Semaphore::wait
 	 	 	 	 	 	[External Code]

Not Flagged		33072	0	Worker Thread	ucrtbased.dll thread	blender.exe!IlmThread::Semaphore::wait
 	 	 	 	 	 	[External Code]

Not Flagged		21732	0	Worker Thread	ucrtbased.dll thread	blender.exe!IlmThread::Semaphore::wait
 	 	 	 	 	 	[External Code]

Not Flagged		23208	0	Worker Thread	ucrtbased.dll thread	blender.exe!IlmThread::Semaphore::wait
 	 	 	 	 	 	[External Code]

Not Flagged		31268	0	Worker Thread	ucrtbased.dll thread	blender.exe!IlmThread::Semaphore::wait
 	 	 	 	 	 	[External Code]

Not Flagged		20624	0	Worker Thread	ucrtbased.dll thread	blender.exe!IlmThread::Semaphore::wait
 	 	 	 	 	 	[External Code]

Not Flagged		33840	0	Worker Thread	ucrtbased.dll thread	blender.exe!IlmThread::Semaphore::wait
 	 	 	 	 	 	[External Code]

Not Flagged		34872	0	Worker Thread	ucrtbased.dll thread	blender.exe!IlmThread::Semaphore::wait
 	 	 	 	 	 	[External Code]

Not Flagged		19640	0	Worker Thread	ucrtbased.dll thread	blender.exe!IlmThread::Semaphore::wait
 	 	 	 	 	 	[External Code]

Not Flagged		13136	0	Worker Thread	ucrtbased.dll thread	blender.exe!IlmThread::Semaphore::wait
 	 	 	 	 	 	[External Code]

Not Flagged		18784	0	Worker Thread	ucrtbased.dll thread	blender.exe!IlmThread::Semaphore::wait
 	 	 	 	 	 	[External Code]

Not Flagged		33904	0	Worker Thread	ucrtbased.dll thread	blender.exe!IlmThread::Semaphore::wait
 	 	 	 	 	 	[External Code]

Not Flagged		28608	0	Worker Thread	ntdll.dll thread	ntdll.dll!00007ff8248ffa54
 	 	 	 	 	 	[External Code]

Not Flagged		36820	0	Worker Thread	ntdll.dll thread	ntdll.dll!00007ff8248ffa54
 	 	 	 	 	 	[External Code]

Not Flagged		29964	0	Worker Thread	ntdll.dll thread	ntdll.dll!00007ff8248ffa54
 	 	 	 	 	 	[External Code]

Not Flagged		32128	0	Worker Thread	OpenAL32.dll thread	win32u.dll!00007ff8221b1164
 	 	 	 	 	 	[External Code]

Not Flagged		27332	0	Worker Thread	alsoft-mixer	OpenAL32.dll!00007fffb88b5859
 	 	 	 	 	 	[External Code]

Not Flagged		13492	0	Worker Thread	combase.dll thread	combase.dll!00007ff822ed9d1b
 	 	 	 	 	 	[External Code]

Not Flagged		29572	0	Worker Thread	ntdll.dll thread	ntdll.dll!00007ff8248ffa54
 	 	 	 	 	 	[External Code]

Not Flagged		35844	0	Worker Thread	ntdll.dll thread	ntdll.dll!00007ff8248ffa54
 	 	 	 	 	 	[External Code]

Not Flagged		28760	0	Worker Thread	nvoglv64.dll thread	nvoglv64.dll!00007fff9a382fca
 	 	 	 	 	 	[External Code]

Not Flagged		25036	0	Worker Thread	nvoglv64.dll thread	nvoglv64.dll!00007fff9a3b9c47
 	 	 	 	 	 	[External Code]

Not Flagged		30868	0	Worker Thread	nvoglv64.dll thread	nvoglv64.dll!00007fff9a3e23c8
 	 	 	 	 	 	[External Code]

Not Flagged		21056	0	Worker Thread	nvoglv64.dll thread	win32u.dll!00007ff8221b9a84
 	 	 	 	 	 	[External Code]

Not Flagged		15372	0	Worker Thread	Wacom_Tablet.dll thread	Wacom_Tablet.dll!00007ffff21436ca
 	 	 	 	 	 	[External Code]

Not Flagged		5772	0	Worker Thread	ucrtbased.dll thread	blender.exe!__ptw32_callUserDestroyRoutines
 	 	 	 	 	 	[External Code]
 	 	 	 	 	 	blender.exe!BLI_condition_wait(pthread_cond_t_ * * cond, pthread_mutex_t_ * * mutex) Line 629
 	 	 	 	 	 	blender.exe!task_scheduler_thread_wait_pop(TaskScheduler * scheduler, Task * * task) Line 363
 	 	 	 	 	 	blender.exe!task_scheduler_thread_run(void * thread_p) Line 445
 	 	 	 	 	 	[External Code]

Not Flagged		13988	0	Worker Thread	ucrtbased.dll thread	blender.exe!__ptw32_callUserDestroyRoutines
 	 	 	 	 	 	[External Code]
 	 	 	 	 	 	blender.exe!BLI_condition_wait(pthread_cond_t_ * * cond, pthread_mutex_t_ * * mutex) Line 629
 	 	 	 	 	 	blender.exe!task_scheduler_thread_wait_pop(TaskScheduler * scheduler, Task * * task) Line 363
 	 	 	 	 	 	blender.exe!task_scheduler_thread_run(void * thread_p) Line 445
 	 	 	 	 	 	[External Code]

Not Flagged		5700	0	Worker Thread	ucrtbased.dll thread	blender.exe!__ptw32_callUserDestroyRoutines
 	 	 	 	 	 	[External Code]
 	 	 	 	 	 	blender.exe!BLI_condition_wait(pthread_cond_t_ * * cond, pthread_mutex_t_ * * mutex) Line 629
 	 	 	 	 	 	blender.exe!task_scheduler_thread_wait_pop(TaskScheduler * scheduler, Task * * task) Line 363
 	 	 	 	 	 	blender.exe!task_scheduler_thread_run(void * thread_p) Line 445
 	 	 	 	 	 	[External Code]

Not Flagged		34488	0	Worker Thread	ucrtbased.dll thread	blender.exe!__ptw32_callUserDestroyRoutines
 	 	 	 	 	 	[External Code]
 	 	 	 	 	 	blender.exe!BLI_condition_wait(pthread_cond_t_ * * cond, pthread_mutex_t_ * * mutex) Line 629
 	 	 	 	 	 	blender.exe!task_scheduler_thread_wait_pop(TaskScheduler * scheduler, Task * * task) Line 363
 	 	 	 	 	 	blender.exe!task_scheduler_thread_run(void * thread_p) Line 445
 	 	 	 	 	 	[External Code]

Not Flagged		28536	0	Worker Thread	ucrtbased.dll thread	blender.exe!__ptw32_callUserDestroyRoutines
 	 	 	 	 	 	[External Code]
 	 	 	 	 	 	blender.exe!BLI_condition_wait(pthread_cond_t_ * * cond, pthread_mutex_t_ * * mutex) Line 629
 	 	 	 	 	 	blender.exe!task_scheduler_thread_wait_pop(TaskScheduler * scheduler, Task * * task) Line 363
 	 	 	 	 	 	blender.exe!task_scheduler_thread_run(void * thread_p) Line 445
 	 	 	 	 	 	[External Code]

Not Flagged		35436	0	Worker Thread	ucrtbased.dll thread	blender.exe!__ptw32_callUserDestroyRoutines
 	 	 	 	 	 	[External Code]
 	 	 	 	 	 	blender.exe!BLI_condition_wait(pthread_cond_t_ * * cond, pthread_mutex_t_ * * mutex) Line 629
 	 	 	 	 	 	blender.exe!task_scheduler_thread_wait_pop(TaskScheduler * scheduler, Task * * task) Line 363
 	 	 	 	 	 	blender.exe!task_scheduler_thread_run(void * thread_p) Line 445
 	 	 	 	 	 	[External Code]

Not Flagged		33272	0	Worker Thread	ucrtbased.dll thread	blender.exe!__ptw32_callUserDestroyRoutines
 	 	 	 	 	 	[External Code]
 	 	 	 	 	 	blender.exe!BLI_condition_wait(pthread_cond_t_ * * cond, pthread_mutex_t_ * * mutex) Line 629
 	 	 	 	 	 	blender.exe!task_scheduler_thread_wait_pop(TaskScheduler * scheduler, Task * * task) Line 363
 	 	 	 	 	 	blender.exe!task_scheduler_thread_run(void * thread_p) Line 445
 	 	 	 	 	 	[External Code]

Not Flagged		22452	0	Worker Thread	ucrtbased.dll thread	blender.exe!__ptw32_callUserDestroyRoutines
 	 	 	 	 	 	[External Code]
 	 	 	 	 	 	blender.exe!BLI_condition_wait(pthread_cond_t_ * * cond, pthread_mutex_t_ * * mutex) Line 629
 	 	 	 	 	 	blender.exe!task_scheduler_thread_wait_pop(TaskScheduler * scheduler, Task * * task) Line 363
 	 	 	 	 	 	blender.exe!task_scheduler_thread_run(void * thread_p) Line 445
 	 	 	 	 	 	[External Code]

Not Flagged	>	33100	0	Worker Thread	ucrtbased.dll thread	blender.exe!fftw_khc2c_register
 	 	 	 	 	 	blender.exe!fftw_khc2c_register()
 	 	 	 	 	 	blender.exe!fftw_null_awake()
 	 	 	 	 	 	blender.exe!fftw_dft_rank_geq2_register()
 	 	 	 	 	 	blender.exe!fftw_rdft2_buffered_register()
 	 	 	 	 	 	blender.exe!fftw_rdft2_solve()
 	 	 	 	 	 	blender.exe!fftw_execute()
 	 	 	 	 	 	blender.exe!ocean_compute_displacement_y(TaskPool * pool, void * UNUSED_taskdata, int UNUSED_threadid) Line 551
 	 	 	 	 	 	blender.exe!task_scheduler_thread_run(void * thread_p) Line 451
 	 	 	 	 	 	[External Code]

Not Flagged		27952	0	Worker Thread	ucrtbased.dll thread	blender.exe!__ptw32_callUserDestroyRoutines
 	 	 	 	 	 	[External Code]
 	 	 	 	 	 	blender.exe!BLI_condition_wait(pthread_cond_t_ * * cond, pthread_mutex_t_ * * mutex) Line 629
 	 	 	 	 	 	blender.exe!task_scheduler_thread_wait_pop(TaskScheduler * scheduler, Task * * task) Line 363
 	 	 	 	 	 	blender.exe!task_scheduler_thread_run(void * thread_p) Line 445
 	 	 	 	 	 	[External Code]

Not Flagged		31340	0	Worker Thread	ucrtbased.dll thread	blender.exe!__ptw32_callUserDestroyRoutines
 	 	 	 	 	 	[External Code]
 	 	 	 	 	 	blender.exe!BLI_condition_wait(pthread_cond_t_ * * cond, pthread_mutex_t_ * * mutex) Line 629
 	 	 	 	 	 	blender.exe!task_scheduler_thread_wait_pop(TaskScheduler * scheduler, Task * * task) Line 363
 	 	 	 	 	 	blender.exe!task_scheduler_thread_run(void * thread_p) Line 445
 	 	 	 	 	 	[External Code]

Not Flagged		2084	0	Worker Thread	ucrtbased.dll thread	blender.exe!__ptw32_callUserDestroyRoutines
 	 	 	 	 	 	[External Code]
 	 	 	 	 	 	blender.exe!BLI_condition_wait(pthread_cond_t_ * * cond, pthread_mutex_t_ * * mutex) Line 629
 	 	 	 	 	 	blender.exe!task_scheduler_thread_wait_pop(TaskScheduler * scheduler, Task * * task) Line 363
 	 	 	 	 	 	blender.exe!task_scheduler_thread_run(void * thread_p) Line 445
 	 	 	 	 	 	[External Code]

Not Flagged		23524	0	Worker Thread	ucrtbased.dll thread	blender.exe!mul_complex_f
 	 	 	 	 	 	blender.exe!mul_complex_f(double * res, double * cmpl, float f) Line 244
 	 	 	 	 	 	blender.exe!ocean_compute_displacement_x(TaskPool * pool, void * UNUSED_taskdata, int UNUSED_threadid) Line 571
 	 	 	 	 	 	blender.exe!task_scheduler_thread_run(void * thread_p) Line 451
 	 	 	 	 	 	[External Code]

Not Flagged		35732	0	Worker Thread	ucrtbased.dll thread	blender.exe!__ptw32_callUserDestroyRoutines
 	 	 	 	 	 	[External Code]
 	 	 	 	 	 	blender.exe!BLI_condition_wait(pthread_cond_t_ * * cond, pthread_mutex_t_ * * mutex) Line 629
 	 	 	 	 	 	blender.exe!task_scheduler_thread_wait_pop(TaskScheduler * scheduler, Task * * task) Line 363
 	 	 	 	 	 	blender.exe!task_scheduler_thread_run(void * thread_p) Line 445
 	 	 	 	 	 	[External Code]

Not Flagged		30344	0	Worker Thread	ucrtbased.dll thread	blender.exe!__ptw32_callUserDestroyRoutines
 	 	 	 	 	 	[External Code]
 	 	 	 	 	 	blender.exe!BLI_condition_wait(pthread_cond_t_ * * cond, pthread_mutex_t_ * * mutex) Line 629
 	 	 	 	 	 	blender.exe!task_scheduler_thread_wait_pop(TaskScheduler * scheduler, Task * * task) Line 363
 	 	 	 	 	 	blender.exe!task_scheduler_thread_run(void * thread_p) Line 445
 	 	 	 	 	 	[External Code]

Not Flagged		23956	0	Worker Thread	nvoglv64.dll thread	nvoglv64.dll!00007fff9a382fca
 	 	 	 	 	 	[External Code]

Not Flagged		37320	0	Worker Thread	nvoglv64.dll thread	nvoglv64.dll!00007fff9a382fca
 	 	 	 	 	 	[External Code]

Not Flagged		16272	0	Worker Thread	nvoglv64.dll thread	nvoglv64.dll!00007fff9a382fca
 	 	 	 	 	 	[External Code]

Not Flagged		28904	0	Worker Thread	nvoglv64.dll thread	nvoglv64.dll!00007fff9a382fca
 	 	 	 	 	 	[External Code]

Not Flagged		22876	0	Worker Thread	nvoglv64.dll thread	nvoglv64.dll!00007fff9a382fca
 	 	 	 	 	 	[External Code]

Not Flagged		37500	0	Worker Thread	nvoglv64.dll thread	nvoglv64.dll!00007fff9a382fca
 	 	 	 	 	 	[External Code]

Not Flagged		13156	0	Worker Thread	nvoglv64.dll thread	nvoglv64.dll!00007fff9a382fca
 	 	 	 	 	 	[External Code]

Not Flagged		17936	0	Worker Thread	nvoglv64.dll thread	nvoglv64.dll!00007fff9a382fca
 	 	 	 	 	 	[External Code]

Just a side note, I had to run a few dozen of times to be able to catch the exceptio, so it's a bit hit and miss.
The other ocean_compute_displacement_x, and ocean_compute_displacement_z are in a for loop and don't seem to be writing to any of the osd->o fields, only reading. The problem seems to be inside fftw.

eeeeeeh, please use file attachments :)

Sorry :D. On a 4k monitor didn't look so big.

Bastien Montagne (mont29) mentioned this in T71040: Ocean modifier crashes blender..May 15 2020, 12:55 PM

Ray Molenkamp (LazyDodo) mentioned this in T58983: Ocean Modifier crashes when setting the resolution to 32.May 15 2020, 6:14 PM