Ocean modifier crashes blender. #71040

New Issue

Vadim · 2019-10-23T10:01:32+02:00

Vadim commented

2019-10-23 10:01:32 +02:00

System Information
Operating system: Windows-10-10.0.18362 64 Bits
Graphics card: GeForce RTX 2070/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 431.86
CPU: Ryzen 5 2600
Memory: 16 Gb.

Blender Version
Broken: version: 2.80 (sub 75), branch: master, commit date: 2019-07-29 14:47, hash: f6cb5f5449
Worked: (optional)

Short description of error
I found this problem in 2.80 stable version and also in current 2.81 build.

Exact steps for others to reproduce the error
Starting new file. Creating plane. Adding Ocean Modifier. Increasing resolution to 32. Blender crashes.
Sometimes it gives the chance to change resolution, but it also crushes when you click Bake Ocean with Generate Normals, Generate Foam(Coverage 2.0), Start 1, End 1.

**System Information** Operating system: Windows-10-10.0.18362 64 Bits Graphics card: GeForce RTX 2070/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 431.86 CPU: Ryzen 5 2600 Memory: 16 Gb. **Blender Version** Broken: version: 2.80 (sub 75), branch: master, commit date: 2019-07-29 14:47, hash: `f6cb5f5449` Worked: (optional) **Short description of error** I found this problem in 2.80 stable version and also in current 2.81 build. **Exact steps for others to reproduce the error** Starting new file. Creating plane. Adding Ocean Modifier. Increasing resolution to 32. Blender crashes. Sometimes it gives the chance to change resolution, but it also crushes when you click Bake Ocean with Generate Normals, Generate Foam(Coverage 2.0), Start 1, End 1.

Vadim commented

2019-10-23 10:01:32 +02:00

Added subscriber: @just_own3d

Daniel Santana commented

2019-10-23 11:12:22 +02:00

Added subscriber: @dgsantana

Daniel Santana commented

2019-10-23 11:12:22 +02:00

Can confirm. Crash on freeing task for ocean_compute_displacement_y. Only happens if you enter directly a high resolution. If increase incremental to 32, the error doesn't occur. Also after that, you can enter any value without crashing.

Daniel Santana commented

2019-10-23 11:22:47 +02:00

It can also happen calling ocean_compute_displacement_x and probably ocean_compute_displacement_z.

Marcin Twarowski commented

2019-10-28 11:10:26 +01:00

Added subscriber: @MarcinTwarowski

Marcin Twarowski commented

2019-10-28 11:10:26 +01:00

Looks like a duplicate of #58983 ?

Daniel Santana commented

2019-10-28 11:20:20 +01:00

Yup it seems. And it may be true that the problem is a conflict between the blender tasks/threads and the internal fftw threads, in which they don't wait on each other. I'm diving a little deeper. But the patch we are discussing should at least solve the threading problem, and avoid the crash. But the Ocean modifier needs more work, because it gets "resimulated" in situations where this shouldn't happen, like moving the object that as no animation.

Jeroen Bakker commented

2020-01-28 09:47:02 +01:00

Added subscriber: @Jeroen-Bakker

Jeroen Bakker commented

2020-01-28 09:47:02 +01:00

Unable to reproduce in B2.80-B2.82 on linux. As others have reproduce this one. I will set it to known issue.

Bastien Montagne commented

2020-05-15 12:55:18 +02:00

Added subscriber: @mont29

Bastien Montagne commented

2020-05-15 12:55:18 +02:00

Changed status from 'Confirmed' to: 'Needs User Info'

Bastien Montagne commented

2020-05-15 12:55:18 +02:00

Cannot reproduce any of this here either with latest master on linux...

Also, backend of our multi-tasking code was switched to TBB recently (and fix proposed in D6121 should "not work" since it should be a no-op change), so if someone on windows could try to reconfirm this issue still happen for them? Thanks.

Cannot reproduce any of this here either with latest master on linux... Also, backend of our multi-tasking code was switched to TBB recently (and fix proposed in [D6121](https://archive.blender.org/developer/D6121) should "not work" since it should be a no-op change), so if someone on windows could try to reconfirm this issue still happen for them? Thanks.

Marcin Twarowski commented

2020-05-15 13:47:00 +02:00

Tested on

Windows-10-10.0.18362-SP0 64 Bits
GeForce GTX 750 Ti/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 445.87
i5-3350P 3.10Ghz
2.83 (sub 16), branch: master, commit date: 2020-05-14 19:49, hash: f716bb3b71

Changing resolution to 32 does not crash. However following these steps:

click Bake Ocean with Generate Normals, Generate Foam(Coverage 2.0), Start 1, End 1.

At resolution 32 did crash Blender.

However, tested on:

Blender version: 2.90 (sub 1), branch: master, commit date: 2020-05-14 22:52, hash: `rBc880e54a95dd`

Simply changing resolution to 32 does crash to desktop.

Tested on > Windows-10-10.0.18362-SP0 64 Bits > GeForce GTX 750 Ti/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 445.87 >i5-3350P 3.10Ghz >2.83 (sub 16), branch: master, commit date: 2020-05-14 19:49, hash: `f716bb3b71` Changing resolution to 32 does not crash. However following these steps: > click Bake Ocean with Generate Normals, Generate Foam(Coverage 2.0), Start 1, End 1. At resolution 32 did crash Blender. However, tested on: ``` Blender version: 2.90 (sub 1), branch: master, commit date: 2020-05-14 22:52, hash: `rBc880e54a95dd` ``` Simply changing resolution to 32 does crash to desktop.

Bastien Montagne commented

2020-05-15 15:33:16 +02:00

Changed status from 'Needs User Info' to: 'Needs Developer To Reproduce'

Bastien Montagne commented

2020-05-15 15:33:16 +02:00

Hrrrmmmm..... I still cannot reproduce, but I have found some discrepancy in threaded code logic in ocean simulation...

Can you please try that patch and see whether you can still reproduce the crash?

P1395: Potential fix for #71040

diff --git a/source/blender/blenkernel/intern/ocean.c b/source/blender/blenkernel/intern/ocean.c
index 8957628c76a..e1fe0db3524 100644
--- a/source/blender/blenkernel/intern/ocean.c
+++ b/source/blender/blenkernel/intern/ocean.c
@@ -678,8 +678,13 @@ void BKE_ocean_simulate(struct Ocean *o, float t, float scale, float chop_amount
   TaskParallelSettings settings;
   BLI_parallel_range_settings_defaults(&settings);
   settings.use_threading = (o->_M > 16);
+
   BLI_task_parallel_range(0, o->_M, &osd, ocean_compute_htilda, &settings);
 
+  /* The other computations depend on `_htilda` and/or `_fft_in` generated by this call, so we have
+   * to ensure that this init call is fully ran before adding the other tasks to the pool. */
+  BLI_task_pool_work_and_wait(pool);
+
   if (o->_do_disp_y) {
     BLI_task_pool_push(pool, ocean_compute_displacement_y, NULL, false, NULL);
   }

Hrrrmmmm..... I still cannot reproduce, but I have found some discrepancy in threaded code logic in ocean simulation... Can you please try that patch and see whether you can still reproduce the crash? [P1395: Potential fix for #71040](https://archive.blender.org/developer/P1395.txt) ``` diff --git a/source/blender/blenkernel/intern/ocean.c b/source/blender/blenkernel/intern/ocean.c index 8957628c76a..e1fe0db3524 100644 --- a/source/blender/blenkernel/intern/ocean.c +++ b/source/blender/blenkernel/intern/ocean.c @@ -678,8 +678,13 @@ void BKE_ocean_simulate(struct Ocean *o, float t, float scale, float chop_amount TaskParallelSettings settings; BLI_parallel_range_settings_defaults(&settings); settings.use_threading = (o->_M > 16); + BLI_task_parallel_range(0, o->_M, &osd, ocean_compute_htilda, &settings); + /* The other computations depend on `_htilda` and/or `_fft_in` generated by this call, so we have + * to ensure that this init call is fully ran before adding the other tasks to the pool. */ + BLI_task_pool_work_and_wait(pool); + if (o->_do_disp_y) { BLI_task_pool_push(pool, ocean_compute_displacement_y, NULL, false, NULL); } ```

Bastien Montagne commented

2020-05-15 16:14:08 +02:00

Changed status from 'Needs Developer To Reproduce' to: 'Needs User Info'

Marcin Twarowski commented

2020-05-16 13:46:30 +02:00

In #71040#932398, @mont29 wrote:
Can you please try that patch and see whether you can still reproduce the crash?

I'm afraid I won't be much help here. Someone else needs to test it.

> In #71040#932398, @mont29 wrote: > Can you please try that patch and see whether you can still reproduce the crash? I'm afraid I won't be much help here. Someone else needs to test it.

Bastien Montagne commented

2020-05-18 16:28:08 +02:00

Hrrrmmmm Actually that patch is pure rubbish, BLI_task_parallel_range() is by design blocking, so guaranteed to be finished before we start adding more tasks to the pool......

Hrrrmmmm Actually that patch is pure rubbish, `BLI_task_parallel_range()` is by design blocking, so guaranteed to be finished before we start adding more tasks to the pool......

Bastien Montagne commented

2020-05-18 16:39:27 +02:00

OK, so potential new candidate (aka next shot in the dark):

P1401: Fix for ocean thread pool crash #71040 and #58983

diff --git a/source/blender/blenkernel/intern/ocean.c b/source/blender/blenkernel/intern/ocean.c
index 8957628c76a..39722a8d1c3 100644
--- a/source/blender/blenkernel/intern/ocean.c
+++ b/source/blender/blenkernel/intern/ocean.c
@@ -951,13 +951,13 @@ void BKE_ocean_init(struct Ocean *o,
     }
   }
 
+  BLI_thread_lock(LOCK_FFTW);
+
   o->_fft_in = (fftw_complex *)MEM_mallocN(o->_M * (1 + o->_N / 2) * sizeof(fftw_complex),
                                            "ocean_fft_in");
   o->_htilda = (fftw_complex *)MEM_mallocN(o->_M * (1 + o->_N / 2) * sizeof(fftw_complex),
                                            "ocean_htilda");
 
-  BLI_thread_lock(LOCK_FFTW);
-
   if (o->_do_disp_y) {
     o->_disp_y = (double *)MEM_mallocN(o->_M * o->_N * sizeof(double), "ocean_disp_y");
     o->_disp_y_plan = fftw_plan_dft_c2r_2d(o->_M, o->_N, o->_fft_in, o->_disp_y, FFTW_ESTIMATE);
@@ -1061,8 +1061,6 @@ void BKE_ocean_free_data(struct Ocean *oc)
     MEM_freeN(oc->_Jxz);
   }
 
-  BLI_thread_unlock(LOCK_FFTW);
-
   if (oc->_fft_in) {
     MEM_freeN(oc->_fft_in);
   }
@@ -1077,6 +1075,8 @@ void BKE_ocean_free_data(struct Ocean *oc)
     MEM_freeN(oc->_kz);
   }
 
+  BLI_thread_unlock(LOCK_FFTW);
+
   BLI_rw_mutex_unlock(&oc->oceanmutex);
 }

OK, so potential new candidate (aka next shot in the dark): [P1401: Fix for ocean thread pool crash #71040 and #58983](https://archive.blender.org/developer/P1401.txt) ``` diff --git a/source/blender/blenkernel/intern/ocean.c b/source/blender/blenkernel/intern/ocean.c index 8957628c76a..39722a8d1c3 100644 --- a/source/blender/blenkernel/intern/ocean.c +++ b/source/blender/blenkernel/intern/ocean.c @@ -951,13 +951,13 @@ void BKE_ocean_init(struct Ocean *o, } } + BLI_thread_lock(LOCK_FFTW); + o->_fft_in = (fftw_complex *)MEM_mallocN(o->_M * (1 + o->_N / 2) * sizeof(fftw_complex), "ocean_fft_in"); o->_htilda = (fftw_complex *)MEM_mallocN(o->_M * (1 + o->_N / 2) * sizeof(fftw_complex), "ocean_htilda"); - BLI_thread_lock(LOCK_FFTW); - if (o->_do_disp_y) { o->_disp_y = (double *)MEM_mallocN(o->_M * o->_N * sizeof(double), "ocean_disp_y"); o->_disp_y_plan = fftw_plan_dft_c2r_2d(o->_M, o->_N, o->_fft_in, o->_disp_y, FFTW_ESTIMATE); @@ -1061,8 +1061,6 @@ void BKE_ocean_free_data(struct Ocean *oc) MEM_freeN(oc->_Jxz); } - BLI_thread_unlock(LOCK_FFTW); - if (oc->_fft_in) { MEM_freeN(oc->_fft_in); } @@ -1077,6 +1075,8 @@ void BKE_ocean_free_data(struct Ocean *oc) MEM_freeN(oc->_kz); } + BLI_thread_unlock(LOCK_FFTW); + BLI_rw_mutex_unlock(&oc->oceanmutex); } ```

Ray molenkamp self-assigned this 2020-05-19 00:02:34 +02:00

Ray molenkamp commented

2020-05-19 01:50:34 +02:00

Changed status from 'Needs User Info' to: 'Resolved'

Ray molenkamp closed this issue

2020-05-19 01:50:34 +02:00

Ray molenkamp commented

2020-05-19 01:50:34 +02:00

solved for now, final solution will be in the 2.90 lib update round.

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Ocean modifier crashes blender. #71040