Page MenuHome

Often crash on reading heavy resources
Closed, DuplicatePublic

Description

System Information
Operating system: MacOS 10.15.2, Linux Ubuntu 20.04
Graphics card: Intel stuff :-(

Blender Version
Broken: 2.9+ (all existing)
Worked: 2.8 (not sure if it is actually not broken, but at least noticeably less encountering such things)

Short description of error
Crash on making complex collection visible in viewport.

Exact steps for others to reproduce the error
Set some collection as invisible in viewport, which has tons of textures and stuff inside.
Then keep it invisible for a while (let the memory changes enough), do some renders.
So if machine has not so much RAM, e.g. 8GB overall, and Blender swaps to a bigger size of it,
like 5-7GB, try to make that collection back visible.

It almost certainly will immediately crash. This bug was started to be very annoying since
2.9 version, and is still in 2.93 Alpha I am trying updating almost every day.

To my eyes it looks like Blender is trying to access some pages it swapped (?) and then
this seems doesn't work for that well.

Additionally to this, crashes was also trying to open just a file browser, e.g. set render
output directory, once Blender allocated a lot of RAM on 8GB memory machine. But these
are almost impossible to replicate, as they are very rare.

Event Timeline

Bo Maryniuk (isbm) updated the task description. (Show Details)
Robert Guetzkow (rjg) changed the task status from Needs Triage to Needs Information from User.EditedJan 27 2021, 10:32 AM

This sounds like you're simply running out of memory. If the content you are trying to display requires more RAM than is available then macOS can try to use the swap file, but once that space is exhausted the application will be terminated. There is nothing Blender can do about this, you would have to make sure that your project works within the constraints of your hardware.

If you suspect that Blender has a memory leak that under certain conditions results in memory remaining allocated in greater quantities than is correct, then we would need more information to investigate this, e.g. exact step by step instruction that would allow us to replicate the problem.

Hi Rob!

Thank you for the reply. Well, certainly Blender should not just kill all the work, but say "Unable to allocate more memory" and just discard the task. I hope we agree here. :)

Second, this is actually much more tricky than just that. I've noticed if I render something, then adjust/render/adjust etc., it even can drop the memory use from like 6GB to 2-3GB (data taken from the status bar, unless it is totally wrong). And then if I try to access the object again, it immediately crashes. Knowing this super-annoying bug, which is, again, not that present in 2.8, I just very often saving the file. So after it crashes, if I restart Blender, reload everything and just continue from that point, I can keep working w/o problems at all, until it again loses a sync and crashes.

It more feels like it is a resource management bug, because it looks like it simply loses a sync of data/resources and then when trying to re-access it, gets it wrong and segfaults. In any case, if Blender knows it is going to run out of memory, it still should be able to prevent crash, rather then just crash, right? But to me it looks a bug on resources re-reading/un-swapping (I don't know the details of that part of the code).

Hope it clarifies?

@Bo Maryniuk (isbm) Blender can at most check if the allocation fails, but if the OOM killer of the OS terminates the process for allocating more than is available, including swap, then there is nothing the software can do about it.

That description does sound like a bug but we need at least a stack trace from the crash reporter that should open afterwards and step by step instructions to reproduce it. Otherwise the developers on macOS won't be able to track down the issue.

The issue you've describe in your last comment doesn't sound like you're running out of memory. That would crash pretty much immediately at the peak of the memory usage not later on when attempting to work on a particular object.

OK, so what's the next steps? I can drop here the result stack from that typical post-mortem window, if that helps.

@Bo Maryniuk (isbm) Yes, please put that in a *.txt file and upload it here.

Rob, here you go. One of the crashes.
It rendered pretty much nice everything, but then a single access to something in the object tree took it down. Status bar was shoing something like 3.5Gb RAM allocated.

Another one. This time about 2Gb RAM allocated, according to the status bar.

Robert Guetzkow (rjg) changed the task status from Needs Information from User to Needs Triage.Feb 6 2021, 6:34 PM

From crash logs this seems related to T87161: Blender randomly crash without reason in 'glDrawElementsInstancedBaseVertex' (in 'OVERLAY_wireframe_draw' or 'workbench_draw_sample')
Will close this as duplicate. Thanks for the report.
Feel free to comment if there is misunderstanding. Will reopen in that case.