Often crash on reading heavy resources #85088

New Issue

Bo Maryniuk · 2021-01-26T21:01:08+01:00

Bo Maryniuk commented

2021-01-26 21:01:08 +01:00

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.

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

Bo Maryniuk commented

2021-01-26 21:01:08 +01:00

Added subscriber: @isbm

Robert Guetzkow commented

2021-01-27 10:32:54 +01:00

Added subscriber: @rjg

Robert Guetzkow commented

2021-01-27 10:32:54 +01:00

Changed status from 'Needs Triage' to: 'Needs User Info'

Robert Guetzkow commented

2021-01-27 10:32:54 +01:00

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.

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.

Bo Maryniuk commented

2021-01-27 22:19:47 +01:00

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?

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?

Robert Guetzkow commented

2021-01-27 22:36:44 +01:00

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

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

Bo Maryniuk commented

2021-01-27 22:45:26 +01:00

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

Robert Guetzkow commented

2021-01-27 22:48:08 +01:00

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

@isbm Yes, please put that in a *.txt file and upload it here. ![2019_12_04_upload_icon_developer_blender_org.png](https://archive.blender.org/developer/F8190038/2019_12_04_upload_icon_developer_blender_org.png)

Bo Maryniuk commented

2021-02-05 18:17:56 +01:00

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.2021-feb-5.txt

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.[2021-feb-5.txt](https://archive.blender.org/developer/F9654611/2021-feb-5.txt)

Bo Maryniuk commented

2021-02-06 17:39:50 +01:00

Another one. This time about 2Gb RAM allocated, according to the status bar.
2021-feb-6.txt

Another one. This time about 2Gb RAM allocated, according to the status bar. [2021-feb-6.txt](https://archive.blender.org/developer/F9672945/2021-feb-6.txt)

Robert Guetzkow commented

2021-02-06 18:34:54 +01:00

Changed status from 'Needs User Info' to: 'Needs Triage'

Pratik Borhade commented

2022-02-23 20:26:59 +01:00

Added subscriber: @PratikPB2123

Pratik Borhade commented

2022-02-23 20:26:59 +01:00

From crash logs this seems related to #87161 (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.

From crash logs this seems related to #87161 (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.

Pratik Borhade commented

2022-02-23 20:27:22 +01:00

Closed as duplicate of #87161

Pratik Borhade closed this issue

2022-02-23 20:27:22 +01:00

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Often crash on reading heavy resources #85088