Too many crashes

For the past few months I’ve been leaving Blender rendering a project rendering overnight in my Mac Studio M1 Ultra. This project crashes at random about half the nights, and that would be about two months of rendering almost every single night.

Making it much harder to troubleshoot is that sometimes it crashes after a few frames, sometimes after dozens of frames, and sometimes not at all.

The macOS crash log for Blender is gigantic, but I’ve read that the important stuff is near the top, so here it is:

Process:               Blender [46245]
Path:                  /Applications/Blender.app/Contents/MacOS/Blender
Identifier:            org.blenderfoundation.blender
Version:               4.1.0 (4.1.0 2024-03-26)
Code Type:             ARM-64 (Native)
Parent Process:        launchd [1]
User ID:               501

Date/Time:             2024-04-20 03:16:50.8493 -0400
OS Version:            macOS 14.4.1 (23E224)
Report Version:        12
Anonymous UUID:        55AF7720-02C9-926E-C7DA-7319E4A60559


Time Awake Since Boot: 470000 seconds

System Integrity Protection: enabled

Crashed Thread:        63

Exception Type:        EXC_BAD_ACCESS (SIGSEGV)
Exception Codes:       KERN_INVALID_ADDRESS at 0x910043fda9017c05 -> 0x000043fda9017c05 (possible pointer authentication failure)
Exception Codes:       0x0000000000000001, 0x910043fda9017c05

Termination Reason:    Namespace SIGNAL, Code 11 Segmentation fault: 11
Terminating Process:   exc handler [46245]

VM Region Info: 0x43fda9017c05 is not in any region.  Bytes after previous region: 74256780196870  Bytes before following region: 30796375032827
      REGION TYPE                    START - END         [ VSIZE] PRT/MAX SHRMOD  REGION DETAIL
      MALLOC_MEDIUM              7460000000-7468000000   [128.0M] rw-/rwx SM=PRV  
--->  GAP OF 0x5f8b98000000 BYTES
      MALLOC_NANO              600000000000-600020000000 [512.0M] rw-/rwx SM=PRV  

And it starts listing all the threads, until it gets to 63, which is the one that crashed and it shows all this:

Thread 63 Crashed:
0   libtbb.dylib                  	       0x10d43aacc void tbb::internal::generic_scheduler::propagate_task_group_state<unsigned long>(unsigned long tbb::task_group_context::*, tbb::task_group_context&, unsigned long) + 192
1   libtbb.dylib                  	       0x10d43a3d0 bool tbb::internal::market::propagate_task_group_state<unsigned long>(unsigned long tbb::task_group_context::*, tbb::task_group_context&, unsigned long) + 240
2   libtbb.dylib                  	       0x10d43a2dc tbb::task_group_context::cancel_group_execution() + 140
3   libtbb.dylib                  	       0x10d438130 tbb::internal::custom_scheduler<tbb::internal::IntelSchedulerTraits>::local_wait_for_all(tbb::task&, tbb::task*) + 412
4   libtbb.dylib                  	       0x10d435ac8 tbb::internal::generic_scheduler::spawn_root_and_wait(tbb::task&, tbb::task*&) + 224
5   libembree4.dylib              	       0x10e62bbfc embree::AccelN::accels_build() + 228
6   libembree4.dylib              	       0x10e670824 embree::Scene::build_cpu_accels() + 1100
7   libembree4.dylib              	       0x10e670c4c embree::Scene::commit_task() + 528
8   libembree4.dylib              	       0x10e673154 tbb::interface9::internal::start_for<tbb::blocked_range<unsigned long>, tbb::internal::parallel_for_body<embree::Scene::commit(bool)::$_4::operator()() const::'lambda'()::operator()() const::'lambda'(unsigned long), unsigned long>, tbb::auto_partitioner const>::execute() + 1092
9   libtbb.dylib                  	       0x10d4389c0 tbb::internal::custom_scheduler<tbb::internal::IntelSchedulerTraits>::process_bypass_loop(tbb::internal::context_guard_helper<false>&, tbb::task*, long) + 428
10  libtbb.dylib                  	       0x10d438058 tbb::internal::custom_scheduler<tbb::internal::IntelSchedulerTraits>::local_wait_for_all(tbb::task&, tbb::task*) + 196
11  libtbb.dylib                  	       0x10d435ac8 tbb::internal::generic_scheduler::spawn_root_and_wait(tbb::task&, tbb::task*&) + 224
12  libembree4.dylib              	       0x10e672cd8 tbb::internal::function_task<embree::Scene::commit(bool)::$_4::operator()() const::'lambda'()>::execute() + 144
13  libtbb.dylib                  	       0x10d4389c0 tbb::internal::custom_scheduler<tbb::internal::IntelSchedulerTraits>::process_bypass_loop(tbb::internal::context_guard_helper<false>&, tbb::task*, long) + 428
14  libtbb.dylib                  	       0x10d438058 tbb::internal::custom_scheduler<tbb::internal::IntelSchedulerTraits>::local_wait_for_all(tbb::task&, tbb::task*) + 196
15  libembree4.dylib              	       0x10e672a78 tbb::internal::task_group_base::wait() + 40
16  libembree4.dylib              	       0x10e672a38 tbb::internal::wait_delegate::operator()() const + 24
17  libtbb.dylib                  	       0x10d426890 tbb::interface7::internal::isolate_within_arena(tbb::interface7::internal::delegate_base&, long) + 92
18  libembree4.dylib              	       0x10e672bbc std::__1::__function::__func<embree::Scene::commit(bool)::$_4, std::__1::allocator<embree::Scene::commit(bool)::$_4>, void ()>::operator()() + 132
19  libembree4.dylib              	       0x10e670ed4 embree::Scene::commit(bool) + 156
20  libembree4.dylib              	       0x10e63d20c rtcCommitScene + 52
21  Blender                       	       0x104ab9d6c ccl::BVHEmbree::build(ccl::Progress&, ccl::Stats*, RTCDeviceTy*, bool) + 476
22  Blender                       	       0x104ac82f8 ccl::CPUDevice::build_bvh(ccl::BVH*, ccl::Progress&, bool) + 144
23  Blender                       	       0x104acb2b4 ccl::MultiDevice::build_bvh(ccl::BVH*, ccl::Progress&, bool) + 744
24  Blender                       	       0x104c809a0 ccl::GeometryManager::device_update_bvh(ccl::Device*, ccl::DeviceScene*, ccl::Scene*, ccl::Progress&) + 648
25  Blender                       	       0x104c7b408 ccl::GeometryManager::device_update(ccl::Device*, ccl::DeviceScene*, ccl::Scene*, ccl::Progress&) + 4228
26  Blender                       	       0x104d04760 ccl::Scene::device_update(ccl::Device*, ccl::Progress&) + 1504
27  Blender                       	       0x104d064b0 ccl::Scene::update(ccl::Progress&) + 148
28  Blender                       	       0x104df4288 ccl::Session::run_update_for_next_iteration() + 1248
29  Blender                       	       0x104df3908 ccl::Session::run_main_render_loop() + 120
30  Blender                       	       0x104df47f0 ccl::Session::thread_render() + 252
31  Blender                       	       0x104df268c ccl::Session::thread_run() + 164
32  Blender                       	       0x104f193a0 ccl::thread::run(void*) + 28
33  libsystem_pthread.dylib       	       0x18de6ef94 _pthread_start + 136
34  libsystem_pthread.dylib       	       0x18de69d34 thread_start + 8

It goes all the way to thread 89, then another reference to thread 63:

Thread 63 crashed with ARM Thread State (64-bit):
    x0: 0x0000000000000001   x1: 0x0000000000000001   x2: 0x000000011ca8cf38   x3: 0x0000000000000001
    x4: 0x0000600018c85c00   x5: 0x0000000000003380   x6: 0x000060000135f380   x7: 0x000060000aa54f00
    x8: 0x000000011ca8cf28   x9: 0x0000000147752f48  x10: 0x910043fda9017bfd  x11: 0x0000000000633a00
   x12: 0x00000071c2800028  x13: 0x00000000ffff8030  x14: 0x0000000000000c00  x15: 0x00000000ffff7dff
   x16: 0x000000018de9f720  x17: 0x00006000009b0c30  x18: 0x0000000000000000  x19: 0x000000011ca8ce00
   x20: 0x0000000000000001  x21: 0x000000078cb49548  x22: 0x0000000000000078  x23: 0x0000000147752f58
   x24: 0x0000000000000000  x25: 0x0000000000000001  x26: 0x000000011ca8cf38  x27: 0x0000000000000001
   x28: 0x00000000ffffff00   fp: 0x000000078cb493b0   lr: 0x000000010d43aaa0
    sp: 0x000000078cb49350   pc: 0x000000010d43aacc cpsr: 0xa0001000
   far: 0x910043fda9017c05  esr: 0x92000005 (Data Abort) byte read Translation fault

There’s a lot more than that, but those lines in the log seem to be the ones related to this.

Now, doesn’t Blender have its own error log? Or anything that will give me a better idea as to why it’s crashing so often, and why it isn’t a specific frame or anything that’s triggering that error?

I don’t know if this has anything to do with these crashes, but I launched Blender from the Terminal and I got this, except that I replaced my name with “username”:

Last login: Sun Apr 14 19:17:26 on ttys000
username@usernames-Mac-Studio ~ % /Applications/Blender.app/Contents/MacOS/Blender
Read prefs: "/Users/username/Library/Application Support/Blender/4.1/config/userpref.blend"
register_class(...):
Info: Registering operator class: 'OBJECT_OT_AlignOperator', bl_idname 'object.align' has been registered before, unregistering previous
Warning: add-on missing 'bl_info', this can cause poor performance!: '/Users/username/Library/Application Support/Blender/4.1/scripts/addons/bpy_debug.py'
Warning: add-on missing 'bl_info', this can cause poor performance!: '/Users/username/Library/Application Support/Blender/4.1/scripts/addons/construct_mesh.py'
Warning: add-on missing 'bl_info', this can cause poor performance!: '/Users/username/Library/Application Support/Blender/4.1/scripts/addons/gen_material.py'
Warning: add-on missing 'bl_info', this can cause poor performance!: '/Users/username/Library/Application Support/Blender/4.1/scripts/addons/lwoObject.py'

Is that a cause for concern?

I don’t know if anyone here can analyze the code, but if it’s thought to be a bug and it can be reproduced, you can report it.

You can find several cases related to bugs in the link below.

The last thing you posted was an indication of an Adon that has a problem while blender is running.

If you run the blender using the terminal application, you can check the recorded usage information even if a collision occurs.
The cause of the problem may remain here.

https://docs.blender.org/manual/en/latest/advanced/command_line/launch/macos.html

※ It would be helpful if you could also upload information on the project scene.
The most common crash problem is lack of RAM.

Information such as the amount of RAM used in the scene and whether it is increasing during rendering may also be helpful.

There are also bug reports about memory leaks on some MAC systems. I don’t know if this is a bug.

1 Like

My first thing to try, is that assuming the final file you are rendering has been optimized for just rendering (ie, a clean/new file, most modifiers applied, etc, etc.

Then run/start up a Blender instance for rendering that is pretty much factory default, any additional addons are removed/disabled (if the rendering file needs those addons to render, then that’s the other thing that needs to be applied/cached, etc).

Yes, but does anyone know what that add-on is? My Google searches show a lot of results, some going back decades because some of the wording is similar. Narrowing it to the last few years gives me no result. And searching for just the name of the file, that also gives me little to do with what it says in my case.

Funny thing is that last night I launched it from the Terminal and it didn’t crash at all the whole night, and at times during today when I was going to be gone for a while and I let it rendering more frames.

This makes me wonder, you can launch Blender from the Terminal, which allows you to see the output if it crashes. But is it possible to simply render a project in Blender without opening the GUI? I had Modo ten years ago, and I remember that I could execute a command to load a scene and render it with the predetermined outputs. That saved some memory by not having to open the GUI at all. Is that an option in Blender?

You didn’t say the project scene, but rather “information on the project scene”. Are you referring to some command that outputs a log with information about the scene? Or do you want me to describe the scene?

Here are a couple of screenshots with some info:

Screenshot 2024-04-23 at 01.15.19

Just to add, this machine has 64 GB in an SoC chip that supposedly makes it available to both the CPU and the GPU, but I’m not totally sure how much exactly the GPU and Blender get. I know it’s not all 64 GB or the machine would be rendered useless.

Sorry, I’m new to Blender, and my previous knowledge of 3D software was Modo 801 10 years ago. I wouldn’t even know how to optimize the project, and sadly, this is a hobby more than anything else, so as much as I would like to live forever and learn everything about everything, I simply do not have the time required to learn everything there is to Blender.

Well, I don’t know if there’s a workaround, but generally speaking, in macOS you cannot launch several instances of one program like you can in Windows. One instance is all you get, unless you do some hack, like I remember something I did once to launch another instance of After Effects. But it’s not a normal thing like it’s in Windows.

If you mean anything else that is a Blender feature, please let me know how to enable that.

  1. I don’t know about Addon. If it’s an additional addon installed, the one used in the lower version may have come in.
    The output of a problem does not mean that it is unusable, but some of them are unusable or cause problems.

If you don’t need it, disable it from the list

  1. If you have no problems using the terminal, try using Command Line Rendering rendering.

https://docs.blender.org/manual/en/latest/advanced/command_line/render.html

  1. The amount of mesh used in the scene does not seem to be small.
    However, there seems to be no problem with the processing.

Generally, consuming a lot of memory is the image used in the material.
Check memory consumption and if there is a problem, you can easily adjust the size, segmentation level, etc. of the image in Simplify.

https://docs.blender.org/manual/en/latest/render/cycles/render_settings/simplify.html#simplify

Command-Line Rendering in the manual.

You need to set the output directories, filenames, & file-types through the GUI, and then save the file. But after that you can render from the command line with a command like:

$ blender -b fileName.blend -f 1..250

where ‘1’ is the start frame, and ‘250’ is your end frame number.
If you crash after completing frame 73, then re-issue the command as

$ blender -b fileName.blend  -f 74..250

In general, it is a good idea to ALWAYS run blender from a command line, as all error messages are printed to the console / terminal window.

1 Like

No real special feature, it’s just that addons can cause random issues, so trying it at factory default and command line like detailed above is a good way to help make sure this are as stable as possible.

Of course if you have made a significant configuration changes then resetting it all could be a little annoying.

It should be possible to save/backup settings and then restore after doing the rendering.

1 Like

Thanks for the tip. Especially because I went to the Terminal to use the CLI command you gave me to render another camera, but before I could even paste it, I saw that I have 171,722 lines of the same error:

So this makes me think…Would I benefit at all from downloading and installing the latest version of Python, since Blender seems to use it extensively? I don’t know what version of Python I have, and my question on the Terminal “What version of Python do I currently have?” gave me a “zsh: no matches found: have?”, which is machine language for “The what now?”

Just an idea. I would do it, but maybe then seconds later I would get a notification from you or someone here saying “Nooooo, don’t install Python 3.12.3 or Blender will never work again!!!” or something like that :smiley:

1 Like

Blender is distributed with and only uses(I believe) that version of Python. You can see it in the 4.1/python folder.

1 Like

Blender is distributed with the Python version that it uses.

If you have one or more Python versions elsewhere on your computer, they are ignored by Blender. Blender’s python is independent of other Pythons and their installed python-modules.

…but a good question to ask!

1 Like

Not sure how I feel about this advice, but going to put it out there anyway.

Given all your errors, etc, this is what I would do, if it was me.

I’d uninstall, manually delete and basically remove any and all references/installs/folders, etc of Blender, including any settings/preferences I can find.

Once done, fully restart the Mac (total reboot, not just logout/login).

I’d then download a fresh copy of Blender 4.1.1 and do a clean install. If at anytime it asks to reuse any existing settings, etc, even during install or on first running Blender, I’d say NO, delete/remove any of it.

I would then maybe even grab a demo file (ideally an animation) and try rendering it, checking Terminal/Blender console for any errors. There really shouldn’t be any.

Then after that, try your own file, avoiding as much as possible enabling any addition addons other then those are are enabled by a default/factory install.

Again, render, there should be no errors.

This is basically the nuclear option, with one of the biggest down sides being any current preference settings are lost, which depending on how much you have changed/customised, could be rather annoying.

However, the thread title is ‘Too many crashes’ and that’s one hell of a error list.

This might be a key issue here. I remember that at one point I went around the add-ons preferences and started enabling add-ons that I thought might be useful. I don’t even know if I used any of them.

Other than doing the “nuclear” option you described, is there a way to set the add-ons list to the default? And it occurs to me that I should even disable some, at least the ones I know for sure I will never use, like some file import/export options for formats that I never would work with.

Actually the name “too many crashes” alluded at too many crashes over time, not the 200k+ error lines in my screenshot, that one was hilarious. I wish I knew what caused that.

OK, so those four files that were showing that particular error, I think they were all from the same add-on, which was to be able to import lwo models. Not a big deal, as I can simply open Modo 801 in my PC (it doesn’t even open on my M1 Mac) convert them to FBXs, and Bob’s your uncle. Or in this case, my uncle.

So I deleted those files, which were in two places, in the user Library/Application Support/Blender/4.1/scripts/addons/, but also in another path I already forgot. I deleted both versions.

So when I open Blender from the Terminal, those four errors don’t show anymore. However, there’s one thing that shows every time I close Blender, and by this I mean close it from the GUI, and it’s this:

Error: Not freed memory blocks: 5, total unfreed memory 0.013275 MB

The numbers are always the same. And this shows every time I close Blender, whether I opened the project, or if I just opened and closed it right away. I don’t know how important that is, I just thought worth mentioning.

Question about this, I tried doing it but it failed because I have the Blend file in a drive that has a name with a space in it. I had seen this in CLI commands a thousand times before, you just put quote marks at the beginning and end of the path. However, in this case, the result was the same.

I guess I can try just launching the file from the one drive I have that has a single name, but does that always have to be the case? Maybe it’s something else but quote marks to tell it that it’s a full path?

Don’t worry too much about this… I almost always get the “Not freed memory blocks” error message after closing blender. Memory leaks are a C++ thing from heap memory management. I vaguely recall reading somewhere a couple years ago that the blender-devs are “cool” with this as a price of blender performance (ie; the fix would be a massive slow-down of blender for no functional improvement).

re: blender command-line…

aside from the quotes around a space-containing filename / pathname, put a ‘\’ (backslash) in front of the spaces. “My spacey name.blend” → “My\ spacey\ name.blend”.

I don’t have a mac, but if I understand correctly, macs are now running a *nix variant under the hood? If that is the case, then there is also a difference between quotes in *nix shells (double-quotes ≠ single-quotes ≠ back-quotes).

search something like “shell difference between quotes” … it will make a difference which you use, especially with \(space). …and the details may vary depending on exactly which shell is your command-line interpreter.

Under FIle | Defaults you can can pick Load Factory Settings as a quick way that should do a fairly complete reset of Blender.

Thanks, I’ll try that!

Well, if by *nix you mean Unix, they have been running a variant of Unix since 2001, not just now. But Unix is not a curse word, so the *nix makes me wonder if you meant something else.

Thanks, indeed I tried that but after I had rendered one of the cameras fully, that means 1400 frames, stopping only at times because I needed to use the machine, but it didn’t crash once. After that I rendered two other cameras from the same project, although they were about half the length.

I think perhaps what caused all those crashes was that I set 4096 samples as the max but 2048 as the min, because leaving the min at 0 still rendered some areas with some weird noise in them. I’m sure that experienced users can tweak the settings knowing what to do exactly, but I figured I’d raise the minimum since I could leave the machine rendering overnight anyway.

i see *nix widely used as a generic term for the collective family of Unices and derivatives (Unix proper, Linux, BSD…).
This https://unix.org/trademark.html says the trademark as of 2020 was (is?) owned by “The Open Group”. See https://en.wikipedia.org/wiki/History_of_Unix for an overview of some of the legal battles surrounding this piece of software and its name.

Unix is not a curse word, until you find yourself on the wrong end of a lawsuit for attempted genericization of someone’s trademark. :slight_smile:

edit:
see https://en.wikipedia.org/wiki/Unix-like for a better description of *nix. I just tried to web-search for “*nix” – I didn’t realize previously how difficult it can be to search for this 4-character string. :slight_smile:

That really isn’t helping your render times and likely not needed for much of the image. You could set the min to like 128, but should really use the noise threshold to control how many samples Cycles uses on areas that are very noisy.

@3Dimensional The error log states that the reason for the crash is a SIGSEGV, that is a segmentation fault. This is most likely caused by a bug in the code so I highly suggest you open a bug report, preferably through Help->Report a bug.