Ocean Modifier crashes when setting the resolution to 32 #58983

New Issue

Sander de Regt · 2018-12-08T00:08:43+01:00

Sander de Regt commented

2018-12-08 00:08:43 +01:00

System Information
Operating system: Windows 10 - Intel i5-3570K cpu 16 GB Ram
Graphics card: Nvidia Geforde GTX 1060 6GB

Blender Version
Broken: blender-2.80.0-git.6a5e8096973-windows64
Worked: 2.79b release

Short description of error
When setting the Ocean modifier resolution to 32 or trying to bake foam/disp/normal maps with this resolution, Blender 2.8 crashes.
If I take the same steps in 2.79b it works as intended.

Exact steps for others to reproduce the error

Add a plane.
Add the Ocean Modifier.
Animate the time from 0 at frame 0 and 10 at frame 250.
Set the tangents of those keys to lineair.
Set the resolution to 32.

or

Open attached file
In the Ocean Modifier set resolution to 32

Sometimes it crashes right away. Other times only after checking 'generate foam' and 'generate normals' and then pressing 'bake'. Poof Crash.
ocean_sim_resol_bug.blend

**System Information** Operating system: Windows 10 - Intel i5-3570K cpu 16 GB Ram Graphics card: Nvidia Geforde GTX 1060 6GB **Blender Version** Broken: blender-2.80.0-git.6a5e8096973-windows64 Worked: 2.79b release **Short description of error** When setting the Ocean modifier resolution to 32 or trying to bake foam/disp/normal maps with this resolution, Blender 2.8 crashes. If I take the same steps in 2.79b it works as intended. **Exact steps for others to reproduce the error** - Add a plane. - Add the Ocean Modifier. - Animate the time from 0 at frame 0 and 10 at frame 250. - Set the tangents of those keys to lineair. - Set the resolution to 32. or - Open attached file - In the Ocean Modifier set resolution to 32 Sometimes it crashes right away. Other times only after checking 'generate foam' and 'generate normals' and then pressing 'bake'. Poof Crash. [ocean_sim_resol_bug.blend](https://archive.blender.org/developer/F8501216/ocean_sim_resol_bug.blend)

Sander de Regt commented

2018-12-08 00:08:43 +01:00

Added subscriber: @SanderdeRegt

Sebastian Parborg commented

2019-01-04 17:10:15 +01:00

Added subscriber: @ZedDB

Sebastian Parborg commented

2019-01-04 17:10:15 +01:00

I can not reproduce this with a build from today. Could you see if this is still an issue for you with a recent build?

Sander de Regt commented

2019-01-04 19:23:58 +01:00

I just tried it with this build and attached file

blender-2.80.0-git.c97c76c01c1d-windows64

and it went 'poof' again.

Ocean_32.blend

Just press 'bake ocean' and Blender disappears. (at least on my system)

I just tried it with this build and attached file blender-2.80.0-git.c97c76c01c1d-windows64 and it went 'poof' again. [Ocean_32.blend](https://archive.blender.org/developer/F6174047/Ocean_32.blend) Just press 'bake ocean' and Blender disappears. (at least on my system)

Sebastian Parborg commented

2019-01-05 19:18:00 +01:00

Still can't reproduce this even with that file. I hit bake and the bake completes without and issues.

Could you try getting the crash if you run blender from the console (cmd.exe): blender.exe 1>out.txt 2>err.txt that will produce two files (out.txt and err.txt).
If they are not empty, can you upload them here?

Still can't reproduce this even with that file. I hit bake and the bake completes without and issues. Could you try getting the crash if you run blender from the console (cmd.exe): `blender.exe 1>out.txt 2>err.txt` that will produce two files (out.txt and err.txt). If they are not empty, can you upload them here?

Sander de Regt commented

2019-01-05 19:37:35 +01:00

That's strange. I've had it happen on two seperate systems.
I'll try the cmd.exe approach and report back.

the err.txt came back empty out.txt is attached

out.txt

That's strange. I've had it happen on two seperate systems. I'll try the cmd.exe approach and report back. the err.txt came back empty out.txt is attached [out.txt](https://archive.blender.org/developer/F6188997/out.txt)

Sander de Regt commented

2019-01-08 19:22:45 +01:00

I just downloaded today's build (january 8th) and the scene I attached earlier still makes Blender vanish. It does this both on my desktop and on my laptop.
@ZedDB what kind of system are you running Blender on? And could the fact that I have multiple 2.8 version concurrently influence my test results?
I still find it strange that 2.79 on the same system does not display this behavior.

I just downloaded today's build (january 8th) and the scene I attached earlier still makes Blender vanish. It does this both on my desktop and on my laptop. @ZedDB what kind of system are you running Blender on? And could the fact that I have multiple 2.8 version concurrently influence my test results? I still find it strange that 2.79 on the same system does not display this behavior.

Sebastian Parborg commented

2019-01-08 19:30:13 +01:00

Added subscribers: @mano-wii, @dfelinto

Sebastian Parborg commented

2019-01-08 19:30:13 +01:00

@SanderdeRegt I'm using linux, so this could be a windows problem. But I'm not sure.

@dfelinto @mano-wii can you guys reproduce this?

@SanderdeRegt I'm using linux, so this could be a windows problem. But I'm not sure. @dfelinto @mano-wii can you guys reproduce this?

Germano Cavalcante commented

2019-01-09 03:03:26 +01:00

Added subscribers: @mont29, @LukasTonne

Germano Cavalcante commented

2019-01-09 03:03:26 +01:00

I've been able to reproduce, it's a problem involving the fftw3 library and threads.

I'm not sure if the problem is on Blender side.

@mont29 and @LukasTonne it seems that you have worked in this area a few times. Can you reproduce the problem?

I've been able to reproduce, it's a problem involving the fftw3 library and threads. I'm not sure if the problem is on Blender side. @mont29 and @LukasTonne it seems that you have worked in this area a few times. Can you reproduce the problem?

Sander de Regt commented

2019-01-09 08:55:49 +01:00

Do 2.79 and 2.8 use the same library? Because in 2.79 it does work without crashing. So something is different between versions in that respect.

Sebastian Parborg commented

2019-01-09 12:26:29 +01:00

@mano-wii on windows, right? I still can't reproduce this on my linux machine with either fftw 3.3.6 or 3.3.8.

Dalai Felinto was assigned by Sebastian Parborg

2019-03-21 12:42:45 +01:00

Dalai Felinto removed their assignment 2019-12-23 16:35:42 +01:00

Germano Cavalcante commented

2020-01-17 19:05:44 +01:00

Changed status from 'Confirmed' to: 'Archived'

Germano Cavalcante closed this issue

2020-01-17 19:05:44 +01:00

Germano Cavalcante self-assigned this 2020-01-17 19:05:44 +01:00

Germano Cavalcante commented

2020-01-17 19:05:44 +01:00

I can only reproduce this on a low end PC.
It appears this crashes because Blender ran out of memory.

While we want to improve Blender to handle such cases memory gracefully, this is not currently considered a bug.

I can only reproduce this on a low end PC. It appears this crashes because Blender ran out of memory. While we want to improve Blender to handle such cases memory gracefully, this is not currently considered a bug.

Benjamin Harris commented

2020-04-04 00:39:56 +02:00

Added subscriber: @benjamin.harris-3

Benjamin Harris commented

2020-04-04 00:39:56 +02:00

I do not think this is a real out of memory situation. I have reproduced this in 2.82a and it only occurs when resolution is exactly 32.
If it were a real out of memory it should crash when resolution is 33 and higher, but these values work fine (tested up to 40).

More likely this is a real arithmetic bug when calculating a memory allocation size, and for some reason 32 is a corner case (possibly a bad 32-bit shift?).
It is possible on high-end systems the bogus allocation succeeds and simply allocates a huge chunk of memory (only using a small portion of it).

From this evidence I think this need to be debugged (narrow down and set a breakpoint on the failing allocation, then backtrack if the size is bogus).

I do not think this is a real out of memory situation. I have reproduced this in 2.82a and it only occurs when resolution is exactly 32. If it were a real out of memory it should crash when resolution is 33 and higher, but these values work fine (tested up to 40). More likely this is a real arithmetic bug when calculating a memory allocation size, and for some reason 32 is a corner case (possibly a bad 32-bit shift?). It is possible on high-end systems the bogus allocation succeeds and simply allocates a huge chunk of memory (only using a small portion of it). From this evidence I think this need to be debugged (narrow down and set a breakpoint on the failing allocation, then backtrack if the size is bogus).

Germano Cavalcante commented

2020-04-28 13:43:07 +02:00

Changed status from 'Archived' to: 'Needs Triage'

Germano Cavalcante reopened this issue

2020-04-28 13:43:07 +02:00

Germano Cavalcante changed title from ~~Ocean Modifier crashes to desktop when baking cache at resolution of 32~~ to Ocean Modifier crashes when setting the resolution to 32

2020-04-29 16:42:26 +02:00

Germano Cavalcante removed their assignment 2020-04-29 16:42:26 +02:00

Germano Cavalcante commented

2020-04-29 16:42:26 +02:00

Changed status from 'Needs Triage' to: 'Confirmed'

Germano Cavalcante commented

2020-04-29 16:44:09 +02:00

I can confirm it in Release Build.
Crash with resolution 32 but not with resolution 33.

I can confirm it in Release Build. Crash with resolution 32 but not with resolution 33.

Bastien Montagne commented

2020-05-15 18:07:52 +02:00

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

Bastien Montagne commented

2020-05-15 18:07:52 +02:00

Same remark as in #71040, can someone on windows please try following patch and report whether it fixes the issue? Thanks.

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);
   }

Same remark as in #71040, can someone on windows please try following patch and report whether it fixes the issue? Thanks. [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); } ```

Ray molenkamp commented

2020-05-15 18:14:24 +02:00

Added subscriber: @LazyDodo

Ray molenkamp commented

2020-05-15 18:14:24 +02:00

D6121 is seemingly another stab at solving the same problem.

[D6121](https://archive.blender.org/developer/D6121) is seemingly another stab at solving the same problem.

Bastien Montagne commented

2020-05-15 19:00:15 +02:00

D6121 is by no mean acceptable solution, 'fix' there should be no-op change, which means it is almost certainly only working 'by chance', and not actually fixing anything...

[D6121](https://archive.blender.org/developer/D6121) is by no mean acceptable solution, 'fix' there should be no-op change, which means it is almost certainly only working 'by chance', and not actually fixing anything...

Germano Cavalcante commented

2020-05-15 19:12:04 +02:00

In #58983#932541, @mont29 wrote:
Same remark as in #71040, can someone on windows please try following patch and report whether it fixes the issue?

Did not fix the issue.

Exception thrown at 0x00007FF674D9ADC9 in blender.exe: 0xC0000005: Access violation writing location 0x000000EF48FF5930.

 	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
 	tbb.dll!00007ff854d9523a()	Unknown
>	blender.exe!tbb::interface7::internal::isolate_impl<void,<lambda_4c4e9cab0012cf46ce574e5cf4859202> const>(const Task::()::__l2::<lambda_4c4e9cab0012cf46ce574e5cf4859202> & f) Line 160	C++

 	[Inline Frame] blender.exe!Task::operator()() Line 118	C++
 	blender.exe!tbb::internal::function_task<Task>::execute() Line 1049	C++
 	[External Code]

> In #58983#932541, @mont29 wrote: > Same remark as in #71040, can someone on windows please try following patch and report whether it fixes the issue? Did not fix the issue. ``` Exception thrown at 0x00007FF674D9ADC9 in blender.exe: 0xC0000005: Access violation writing location 0x000000EF48FF5930. ``` ``` 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 tbb.dll!00007ff854d9523a() Unknown > blender.exe!tbb::interface7::internal::isolate_impl<void,<lambda_4c4e9cab0012cf46ce574e5cf4859202> const>(const Task::()::__l2::<lambda_4c4e9cab0012cf46ce574e5cf4859202> & f) Line 160 C++ [Inline Frame] blender.exe!Task::operator()() Line 118 C++ blender.exe!tbb::internal::function_task<Task>::execute() Line 1049 C++ [External Code] ```

Bastien Montagne commented

2020-05-18 12:05:53 +02:00

Then we need someone on windows to investigate and actually understand that issue...

Bastien Montagne commented

2020-05-18 16:39:53 +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); } ```

Germano Cavalcante commented

2020-05-18 19:38:35 +02:00

@mont29, still crashes :
Same backtrace

@mont29, still crashes :\ Same backtrace

Ray molenkamp self-assigned this 2020-05-18 20:58:35 +02:00

Ray molenkamp commented

2020-05-18 20:58:35 +02:00

heh... neat... will do a write up later.