Eevee Motion blur crash rendering animation with steps set to higher value #78321

New Issue

Bohdan Lvov · 2020-06-26T17:54:23+02:00

Bohdan Lvov commented

2020-06-26 17:54:23 +02:00

System Information
Operating system: Windows-10-10.0.19041-SP0 64 Bits
Graphics card: GeForce GTX 970/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 451.48

Blender Version
Broken: version: 2.90.0 Alpha, branch: master, commit date: 2020-06-25 21:53, hash: 62aa103d48

Short description of error
Blender crashes while trying to render an animation with Motion Blur enabled and wildly spinning cube in it. Apparently Steps value playing a role in it, since crash happens when I set Steps to anything above 4 increasingly faster - if on 5 it will render ~40 frames, on 16 steps it's rarely passing father than 15th frame.

Exact steps for others to reproduce the error

Open a file:

cube2.blend

Press CTRL+F12

**System Information** Operating system: Windows-10-10.0.19041-SP0 64 Bits Graphics card: GeForce GTX 970/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 451.48 **Blender Version** Broken: version: 2.90.0 Alpha, branch: master, commit date: 2020-06-25 21:53, hash: `62aa103d48` **Short description of error** Blender crashes while trying to render an animation with Motion Blur enabled and wildly spinning cube in it. Apparently Steps value playing a role in it, since crash happens when I set Steps to anything above 4 increasingly faster - if on 5 it will render ~40 frames, on 16 steps it's rarely passing father than 15th frame. **Exact steps for others to reproduce the error** 1. Open a file: [cube2.blend](https://archive.blender.org/developer/F8645636/cube2.blend) 2. Press CTRL+F12

Bohdan Lvov commented

2020-06-26 17:54:23 +02:00

Added subscriber: @ostapblender

blender-admin commented

2020-06-26 17:54:23 +02:00

#79093 was marked as duplicate of this issue

blender-admin commented

2020-06-26 17:54:23 +02:00

#79039 was marked as duplicate of this issue

blender-admin commented

2020-06-26 17:54:23 +02:00

#78739 was marked as duplicate of this issue

blender-admin commented

2020-06-26 17:54:23 +02:00

#78483 was marked as duplicate of this issue

blender-admin commented

2020-06-26 17:54:23 +02:00

#78528 was marked as duplicate of this issue

blender-admin commented

2020-06-26 17:54:23 +02:00

#78329 was marked as duplicate of this issue

blender-admin commented

2020-06-26 17:54:23 +02:00

#78372 was marked as duplicate of this issue

Joran commented

2020-06-27 00:31:06 +02:00

Added subscriber: @JoranKlaui

Alaska commented

2020-06-28 03:09:49 +02:00

Added subscriber: @Big_Blend

Alaska commented

2020-06-28 03:09:58 +02:00

Added subscribers: @Eary, @chafouin

Richard Antalik commented

2020-06-29 19:54:16 +02:00

Added subscriber: @iss

Richard Antalik commented

2020-06-29 19:54:16 +02:00

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

Richard Antalik commented

2020-06-29 19:54:16 +02:00

I got somewhat random stack trace, but always in bpy_class_call

 	python37.dll!00007ff9d0926f8c()	Unknown
 	python37.dll!00007ff9d0906635()	Unknown
 	python37.dll!00007ff9d0906a22()	Unknown
 	python37.dll!00007ff9d09d42bf()	Unknown
 	python37.dll!00007ff9d09d10b8()	Unknown
 	python37.dll!00007ff9d0906685()	Unknown
>	blender.exe!bpy_class_call(bContext * C, PointerRNA * ptr, FunctionRNA * func, ParameterList * parms) Line 8513	C

 	blender.exe!header_draw(const bContext * C, Header * hdr) Line 707	C
 	blender.exe!ED_region_header_layout(const bContext * C, ARegion * region) Line 2872	C
 	blender.exe!ED_region_do_layout(bContext * C, ARegion * region) Line 505	C
 	blender.exe!wm_draw_window_offscreen(bContext * C, wmWindow * win, bool stereo) Line 668	C
 	blender.exe!wm_draw_window(bContext * C, wmWindow * win) Line 841	C
 	blender.exe!wm_draw_update(bContext * C) Line 1042	C
 	blender.exe!WM_main(bContext * C) Line 482	C
 	blender.exe!main(int argc, const unsigned char * * UNUSED_argv_c) Line 534	C
 	[External Code]

I got somewhat random stack trace, but always in `bpy_class_call` ``` python37.dll!00007ff9d0926f8c() Unknown python37.dll!00007ff9d0906635() Unknown python37.dll!00007ff9d0906a22() Unknown python37.dll!00007ff9d09d42bf() Unknown python37.dll!00007ff9d09d10b8() Unknown python37.dll!00007ff9d0906685() Unknown > blender.exe!bpy_class_call(bContext * C, PointerRNA * ptr, FunctionRNA * func, ParameterList * parms) Line 8513 C blender.exe!header_draw(const bContext * C, Header * hdr) Line 707 C blender.exe!ED_region_header_layout(const bContext * C, ARegion * region) Line 2872 C blender.exe!ED_region_do_layout(bContext * C, ARegion * region) Line 505 C blender.exe!wm_draw_window_offscreen(bContext * C, wmWindow * win, bool stereo) Line 668 C blender.exe!wm_draw_window(bContext * C, wmWindow * win) Line 841 C blender.exe!wm_draw_update(bContext * C) Line 1042 C blender.exe!WM_main(bContext * C) Line 482 C blender.exe!main(int argc, const unsigned char * * UNUSED_argv_c) Line 534 C [External Code] ```

Scott Ramsay commented

2020-06-29 23:03:19 +02:00

Added subscriber: @smramsay

Joran commented

2020-07-02 15:38:52 +02:00

#78528 and #78483 seem to be related to the same issue

Richard Antalik commented

2020-07-03 00:48:54 +02:00

Added subscriber: @sharaths21312

Clément Foucault commented

2020-07-03 01:36:06 +02:00

Added subscriber: @fclem

Clément Foucault commented

2020-07-03 01:36:06 +02:00

I'm pretty sure it's not the motion blur patch causing this as I experienced that before its development. @iss could you bisect to find when this started?

Also another trick to see if that's really linked to motion blur is to set Render In Keep Interface in the user preference temp window setting.

I'm pretty sure it's not the motion blur patch causing this as I experienced that before its development. @iss could you bisect to find when this started? Also another trick to see if that's really linked to motion blur is to set Render In Keep Interface in the user preference temp window setting.

Richard Antalik commented

2020-07-03 01:50:38 +02:00

In #78321#971964, @fclem wrote:
I'm pretty sure it's not the motion blur patch causing this as I experienced that before its development. @iss could you bisect to find when this started?

Also another trick to see if that's really linked to motion blur is to set Render In Keep Interface in the user preference temp window setting.

Will check this out.

> In #78321#971964, @fclem wrote: > I'm pretty sure it's not the motion blur patch causing this as I experienced that before its development. @iss could you bisect to find when this started? > > Also another trick to see if that's really linked to motion blur is to set Render In Keep Interface in the user preference temp window setting. Will check this out.

Richard Antalik commented

2020-07-03 03:05:20 +02:00

In #78321#971964, @fclem wrote:
I'm pretty sure it's not the motion blur patch causing this as I experienced that before its development. @iss could you bisect to find when this started?

Can not reproduce before 439b40e601

Also another trick to see if that's really linked to motion blur is to set Render In Keep Interface in the user preference temp window setting.

No change after setting this.

> In #78321#971964, @fclem wrote: > I'm pretty sure it's not the motion blur patch causing this as I experienced that before its development. @iss could you bisect to find when this started? Can not reproduce before 439b40e601f8cdae9a12fc3f503e9e6acdd596d5 > Also another trick to see if that's really linked to motion blur is to set Render In Keep Interface in the user preference temp window setting. No change after setting this.

Germano Cavalcante commented

2020-07-03 16:07:15 +02:00

Added subscribers: @AmirShehata, @mano-wii

Richard Antalik commented

2020-07-09 09:04:40 +02:00

Added subscriber: @V-prime

Joran commented

2020-07-11 17:22:31 +02:00

In #78321#971964, @fclem wrote:
I'm pretty sure it's not the motion blur patch causing this as I experienced that before its development. @iss could you bisect to find when this started?

Also another trick to see if that's really linked to motion blur is to set Render In Keep Interface in the user preference temp window setting.

I did some testing by running Blender from the command line with 'blender.exe -b blur.blend -a' after which it rendered a full 250 frame animation without any problems. The 'Keep Interface' option didn't change anything for me, but this does indeed confirm it is the fault of an underlying problem.

BlurRender.mp4

> In #78321#971964, @fclem wrote: > I'm pretty sure it's not the motion blur patch causing this as I experienced that before its development. @iss could you bisect to find when this started? > > Also another trick to see if that's really linked to motion blur is to set Render In Keep Interface in the user preference temp window setting. I did some testing by running Blender from the command line with 'blender.exe -b blur.blend -a' after which it rendered a full 250 frame animation without any problems. The 'Keep Interface' option didn't change anything for me, but this does indeed confirm it is the fault of an underlying problem. [BlurRender.mp4](https://archive.blender.org/developer/F8686483/BlurRender.mp4)

Zach Hixson commented

2020-07-12 19:47:38 +02:00

Added subscriber: @ZachHixson

Zach Hixson commented

2020-07-12 19:47:38 +02:00

I've been running into the same problem, and also found that rendering from the command line fixes crashing when using motion blur.

Also in certain scenes where I was testing motion blur, I found that raising motion blur steps seems to increase the chance of a crash, but raising the "Max Blur," lowers the chance of a crash if the steps have been increased. I don't know if this is just a coincidence, but it might be worth looking into.

I've been running into the same problem, and also found that rendering from the command line fixes crashing when using motion blur. Also in certain scenes where I was testing motion blur, I found that raising motion blur steps seems to increase the chance of a crash, but raising the "Max Blur," lowers the chance of a crash if the steps have been increased. I don't know if this is just a coincidence, but it might be worth looking into.

Clément Foucault commented

2020-07-18 16:21:28 +02:00

This comment was removed by @fclem

*This comment was removed by @fclem*

Clément Foucault commented

2020-07-18 16:27:06 +02:00

Added subscribers: @Sergey, @brecht

Clément Foucault commented

2020-07-18 16:27:06 +02:00

After investigation it seems to be related to python & threading.

Removing the calls to RE_engine_frame_set fix the issue but obvisouly removes the motion blur.

In cycles the frame_set calls are protected by python_thread_state_restore(python_thread_state); and python_thread_state_save(python_thread_state);.

I tried using the BPy_BEGIN_ALLOW_THREADS & BPy_END_ALLOW_THREADS pair to protect the RE_engine_frame_set call in eevee_render_to_image but it seems to have no effect.

@Sergey @brecht I know little about python issues with threading. What is be the correct way to fix this?

After investigation it seems to be related to python & threading. Removing the calls to `RE_engine_frame_set` fix the issue but obvisouly removes the motion blur. In cycles the `frame_set` calls are protected by `python_thread_state_restore(python_thread_state);` and `python_thread_state_save(python_thread_state);`. I tried using the `BPy_BEGIN_ALLOW_THREADS` & `BPy_END_ALLOW_THREADS` pair to protect the `RE_engine_frame_set` call in `eevee_render_to_image` but it seems to have no effect. @Sergey @brecht I know little about python issues with threading. What is be the correct way to fix this?

Evan Wilson commented

2020-07-18 18:14:32 +02:00

Added subscriber: @EAW

Evan Wilson commented

2020-07-18 18:14:32 +02:00

You_Can_Act.crash.txt

You_Can_Act_v2.crash.txt

You_Can_Act.crash4.txt

You_Can_Act.crash3.txt

From the first 2 stack traces:

blender.exe         :0x00007FF62CB24460  BLI_timer_execute C:\blender-git\blender\source\blender\blenlib\intern\BLI_timer.c:135```
Are two timers running simultaneously, creating a race condition?  Crash 3 and 4 don't have this in their stack traces.

[You_Can_Act.crash.txt](https://archive.blender.org/developer/F8704460/You_Can_Act.crash.txt) [You_Can_Act_v2.crash.txt](https://archive.blender.org/developer/F8704459/You_Can_Act_v2.crash.txt) [You_Can_Act.crash4.txt](https://archive.blender.org/developer/F8704461/You_Can_Act.crash4.txt) [You_Can_Act.crash3.txt](https://archive.blender.org/developer/F8704462/You_Can_Act.crash3.txt) From the first 2 stack traces: ```blender.exe :0x00007FF6292F7130 py_timer_execute C:\blender-git\blender\source\blender\python\intern\bpy_app_timers.c:68 blender.exe :0x00007FF62CB24460 BLI_timer_execute C:\blender-git\blender\source\blender\blenlib\intern\BLI_timer.c:135``` Are two timers running simultaneously, creating a race condition? Crash 3 and 4 don't have this in their stack traces.

Evan Wilson commented

2020-07-18 21:59:19 +02:00

Added subscriber: @TheCrowdedOne

Evan Wilson commented

2020-07-18 22:11:32 +02:00

Note: I couldn't get it to crash using a debug build.

Clément Foucault commented

2020-07-20 09:03:35 +02:00

Added subscriber: @Ben100

Sergey Sharybin commented

2020-07-20 11:27:09 +02:00

@fclem, the RE_engine_frame_set already contains BPy_BEGIN_ALLOW_THREADS and BPy_END_ALLOW_THREADS. From from reading some code and doing a guess, did you try to add similar python_thread_state_restore / python_thread_state_save in the eevee_render_to_image ?

@fclem, the `RE_engine_frame_set` already contains `BPy_BEGIN_ALLOW_THREADS` and `BPy_END_ALLOW_THREADS`. From from reading some code and doing a guess, did you try to add similar `python_thread_state_restore` / `python_thread_state_save` in the `eevee_render_to_image` ?

Brecht Van Lommel commented

2020-07-20 14:30:24 +02:00

The Python stuff here is only really needed when calling frame set from the Python API. What it does is releases the Python GIL while the depsgraph is being updated, so that other Python code like redrawing the UI can still be done while that happens.

The simplest solution may be to ensure that Python stuff is only done when called through the RNA API, and not when Eevee calls it directly.

The Python stuff here is only really needed when calling frame set from the Python API. What it does is releases the Python GIL while the depsgraph is being updated, so that other Python code like redrawing the UI can still be done while that happens. The simplest solution may be to ensure that Python stuff is only done when called through the RNA API, and not when Eevee calls it directly.

Brecht Van Lommel commented

2020-07-20 14:33:03 +02:00

A general solution to this would to make add some flag to RNA functions to indicate if they need to save / restore the thread safe, and then heavy function calls like frame set can be marked that way. That way this Python stuff could be isolated to the python/ module.

A general solution to this would to make add some flag to RNA functions to indicate if they need to save / restore the thread safe, and then heavy function calls like frame set can be marked that way. That way this Python stuff could be isolated to the `python/` module.

blender-admin commented

2020-07-20 17:23:18 +02:00

This issue was referenced by 4432209849

This issue was referenced by 443220984978bfc982799848762d77bc1d10e8c0

Clément Foucault commented

2020-07-20 17:23:53 +02:00

Changed status from 'Confirmed' to: 'Resolved'

Clément Foucault closed this issue

2020-07-20 17:23:53 +02:00

Clément Foucault self-assigned this 2020-07-20 17:23:53 +02:00

arya bagus commented

2020-12-03 04:02:30 +01:00