Page MenuHome

Ocean Modifier crashes when setting the resolution to 32
Closed, ResolvedPublicBUG

Description

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.

Event Timeline

Sebastian Parborg (zeddb) lowered the priority of this task from 90 to 30.Jan 4 2019, 5:10 PM

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?

I just tried it with this build and attached file

blender-2.80.0-git.c97c76c01c1d-windows64

and it went 'poof' again.

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

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?

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

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.
@Sebastian Parborg (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'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.

@Bastien Montagne (mont29) and @Lukas Toenne (lukastoenne) it seems that you have worked in this area a few times. Can you reproduce the problem?

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.

@Germano Cavalcante (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.

Jacques Lucke (JacquesLucke) raised the priority of this task from 30 to 90.Mar 7 2019, 2:58 PM
Sebastian Parborg (zeddb) lowered the priority of this task from 90 to Normal.

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 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 (mano-wii) reopened this task as Needs Triage.Apr 28 2020, 1:43 PM
Germano Cavalcante (mano-wii) renamed this task from Ocean Modifier crashes to desktop when baking cache at resolution of 32 to Ocean Modifier crashes when setting the resolution to 32.EditedApr 29 2020, 4:42 PM
Germano Cavalcante (mano-wii) changed the task status from Needs Triage to Confirmed.
Germano Cavalcante (mano-wii) removed Germano Cavalcante (mano-wii) as the assignee of this task.
Germano Cavalcante (mano-wii) updated the task description. (Show Details)
Germano Cavalcante (mano-wii) changed the subtype of this task from "Report" to "Bug".

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

Bastien Montagne (mont29) changed the task status from Confirmed to Needs Information from User.May 15 2020, 6:07 PM

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

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

D6121 is seemingly another stab at solving the same problem.

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...

Same remark as in T71040, 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]

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

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

1diff --git a/source/blender/blenkernel/intern/ocean.c b/source/blender/blenkernel/intern/ocean.c
2index 8957628c76a..39722a8d1c3 100644
3--- a/source/blender/blenkernel/intern/ocean.c
4+++ b/source/blender/blenkernel/intern/ocean.c
5@@ -951,13 +951,13 @@ void BKE_ocean_init(struct Ocean *o,
6 }
7 }
8
9+ BLI_thread_lock(LOCK_FFTW);
10+
11 o->_fft_in = (fftw_complex *)MEM_mallocN(o->_M * (1 + o->_N / 2) * sizeof(fftw_complex),
12 "ocean_fft_in");
13 o->_htilda = (fftw_complex *)MEM_mallocN(o->_M * (1 + o->_N / 2) * sizeof(fftw_complex),
14 "ocean_htilda");
15
16- BLI_thread_lock(LOCK_FFTW);
17-
18 if (o->_do_disp_y) {
19 o->_disp_y = (double *)MEM_mallocN(o->_M * o->_N * sizeof(double), "ocean_disp_y");
20 o->_disp_y_plan = fftw_plan_dft_c2r_2d(o->_M, o->_N, o->_fft_in, o->_disp_y, FFTW_ESTIMATE);
21@@ -1061,8 +1061,6 @@ void BKE_ocean_free_data(struct Ocean *oc)
22 MEM_freeN(oc->_Jxz);
23 }
24
25- BLI_thread_unlock(LOCK_FFTW);
26-
27 if (oc->_fft_in) {
28 MEM_freeN(oc->_fft_in);
29 }
30@@ -1077,6 +1075,8 @@ void BKE_ocean_free_data(struct Ocean *oc)
31 MEM_freeN(oc->_kz);
32 }
33
34+ BLI_thread_unlock(LOCK_FFTW);
35+
36 BLI_rw_mutex_unlock(&oc->oceanmutex);
37 }
38

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

Ray molenkamp (LazyDodo) closed this task as Resolved.May 19 2020, 1:50 AM

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