Page MenuHome

Cranking up the number of subdivisions causes an access violation and blender crashes.
Closed, InvalidPublic

Description

System Information
Operating system: Win 10
Graphics card: GTX 970

Blender Version
Blender 2.90.0
Build: 2020-08-31 10:00:13 Windows Release

Short description of error
Seems that when I crank up the subdivision on a object the application crashes.

Exact steps for others to reproduce the error
Load the .blend file provided.
Hit rend and get access violation.

Console output:
Calloc returns null: len=3221225472 in CDMLoop, total 3402049940
Calloc returns null: len=3221225472 in CDMLoop, total 851913628
Calloc returns null: len=1744830488 in subdiv accumulated normals, total 851913628
Error : EXCEPTION_ACCESS_VIOLATION
Address : 0x00007FF661D137D7
Module : blender.exe
Thread : 000054b0

Event Timeline

Calloc returns null: len=3221225472

That says a request for memory (3,221,225,472 bytes) returned null.
You are out of memory.

Seems reasonable. Should it cause the application to crash tho? A warning or some kind of operation failed message with a reason why would probably be better ux than the application dumping.

First 10 times it happend in other scenarios I had no idea why. I didnt even try crazy subdivisions, just following a donut tutorial. I just restarted the application and everything was fine. :)

Robert Guetzkow (rjg) closed this task as Invalid.EditedWed, Sep 16, 6:41 PM
Robert Guetzkow (rjg) claimed this task.

@Jonas Engblom (Engblom) Once you run out of memory it's very difficult for the software to handle the situation gracefully. One could try to display an error message in the UI, but since it can't allocate any more memory this is also likely going to fail as well. The operating system will simply terminate the process and the application has not control over this.

First 10 times it happend in other scenarios I had no idea why. I didnt even try crazy subdivisions, just following a donut tutorial. I just restarted the application and everything was fine. :)

You may have had a high poly count on the base mesh to begin with.

I'm closing this ticket, because this is not considered a bug in Blender.

I'm sure my mesh is fubar since I just started learning this awesome piece of software. :)

Blender tried to allocate 3 gigs and failed. Surely a dialog/message box is a bit cheaper than that. Maybe have a cutoffpoint?
I get that you don't have time to fix all the bugs reported and/or that the architecture doesn't support it easily. Just found it non-user friendly and wanted to contribute with a bug report, keep up the good work! :)

If I get bitten by blender I'll try to drop by and contribute some code aswell!

@Jonas Engblom (Engblom) The previously allocated memory remains allocated though and once the call to calloc fails you don't know how much memory, if anything, is left to allocate. Determining how much is actually left is difficult due to virtual memory and as I've said before, once you get close enough to the limits the OS can decide to terminate the application. Theoretically, if Blender was designed that way, it could check the return value of calloc, stop proceeding with the subdivision level calculation if it is NULL, reduce the level of subdivisions, free memory and then display a warning. This approach would be the ideal implementation, but it is still not entirely bullet proof.

Maybe have a cutoffpoint?

That would be one alternative, adding a configurable upper limit for allocatable memory. This is not a definitive solution though. If multiple applications try to concurrently allocate large amounts memory, it may still happen that you're running out of memory and one or more get terminated.

I get that you don't have time to fix all the bugs reported and/or that the architecture doesn't support it easily. Just found it non-user friendly and wanted to contribute with a bug report, keep up the good work! :)

We really appreciate your report and your enthusiasm trying to improve Blender. In this case it's more of a design issue / generally difficult to handle situation in software. I agree though, the current handling is not ideal. However, crashes caused by running out of memory aren't considered bugs according to the Triaging Playbook (the official rules that are used to moderate the bug tracker), hence I had to close the ticket.

I'll try to drop by and contribute some code aswell!

You're very welcome to! Blender's wiki has a guide to get you started. Instructions for building Blender, how to contribute code and how patches can be submitted for code review can be found there as well.