Blender 2.78c (and old versions) Crash when Render
Closed, ArchivedPublic

Description

System Information
Windows 7 Ultimate SP1
Geforce MX 660 TI

Blender Version
Broken: 2.78c (and old versions)
Worked: (optional)

Short description of error

If I turn on Viewport render mode to "Rendered" and I want render scene with "F12" (with Blender Render), usually crash Blender. But if Viewport render mode not "Rendered", this not happen. And happen this for any scene...

Exact steps for others to reproduce the error
Based on a (as simple as possible) attached .blend file with minimum amount of steps

Details

Type
Bug

Was crash log generated? Please upload if it does. Thanks.
https://docs.blender.org/manual/en/dev/troubleshooting/crash.html

try also run blender with command line option -d to enable debugging. try copy paste the result in a text file and upload it here.

Blender didn't create text file after crash. I use debug mode, my file is saved, and no text file created on file directory or Temp directory. Only create "blend" file on Temp directory.

But I think, if when Viewport render isn't finish render, and I press F12, usually crash. Especially I increase Sun light's Raytrace shadow Samples over to 8.

Brecht Van Lommel (brecht) triaged this task as Incomplete priority.Jul 16 2017, 1:29 AM

Unless this happens with the default scene, we need a .blend file to reproduce this problem.

I send a scene file, if you want. Bu this issue happens all scenes...

Rotate several times Vieport Realtime Render panel and F12, start render and after stop. Repeat 3-4 times, and after crash, also if Viewport Render operation not finish and press F12.

I can't recreate the crash. Win 7 + GTX 750. I notice the first time I press F12, twice the renderer windows says "Not Responding" but after a while it continues rendering. I repeat rotate the viewport (causing it re-render) and presses F12.

You must increase Sun Light's sample ratio (by this way realtime render time increase). and when NOT FINISH Viewport Render, press F12 and render. 3-4 times after Blender crash, not say anything, not show message box, not create debug log, only crash and close...

I managed to get it to crash, I think at that time Sun sample = 55. But its rarely happens (as in hard me to re-create it), as if it was random.

OK. I can confirm this. Attaching suncrash.txt (the -d export) and also crash log crash.crash.txt

sample actually doesn't have to go that far. The second time I managed to make it crash it was around 15.

C:\Blender\blendercode\build_windows_Release_x64_vc14_Debug\bin\Debug>blender -d > suncrash.txt
Vendor: NVIDIA Corporation
Renderer: GeForce GTX 750/PCIe/SSE2
Version: 4.5.0 NVIDIA 376.51
Vendor: NVIDIA Corporation
Renderer: GeForce GTX 750/PCIe/SSE2
Version: 4.5.0 NVIDIA 376.51
Error: EXCEPTION_ACCESS_VIOLATION

Forgot to mention, it was EXCEPTION_ACCESS_VIOLATION.

Visual C++ 2015 debugging gives this info. I hope it helps?

Exception thrown at 0x000000001D89CE18 (python35_d.dll) in blender.exe: 0xC0000005: Access violation reading location 0x0000000000000020.

If there is a handler for this exception, the program may be safely continued.
Fable Fox (fablefox) added a comment.EditedJul 25 2017, 7:26 PM

This is what Visual Studio 2015 debugging gives. The location stays the same.

Unhandled exception at 0x000000001D89CE18 (python35_d.dll) in blender.exe: 0xC0000005: Access violation reading location 0x0000000000000020.

If there is a handler for this exception, the program may be safely continued.

It's this function

static int bpy_class_call(bContext *C, PointerRNA *ptr, FunctionRNA *func, ParameterList *parms)


#ifdef USE_PEDANTIC_WRITE
			rna_disallow_writes = is_readonly ? true : false;
#endif
			/* *** Main Caller *** */

			ret = PyObject_Call(item, args, NULL);  <----- next statement to continue after breakpoint.

			/* *** Done Calling *** */
Bastien Montagne (mont29) raised the priority of this task from Incomplete to Confirmed.Aug 1 2017, 10:59 PM
Sergey Sharybin (sergey) closed this task as Archived.Sep 13 2017, 4:02 PM
Sergey Sharybin (sergey) claimed this task.

This is a threading conflict between viewport and render thread. Trying rendering Fullscreen should help here.

There is ongoing worlk in blender2.8 branch to solve such conflicts by having dedicated dependency graphs for each of the renderers. That is the only reliable way to solve this issue, but it'll surely take some time still.

Thanks for the report, but closing it now. Please stay tuned for 2.8 release! :)