Page MenuHome

Crash: EXC_I386_DIV (divide by zero) crash on MacOS with custom operator
Closed, ArchivedPublic

Description

System Information
MacOS systems running AMD gpus with 2GB of video RAM

Blender Version
Broken: 2.92.0

Short description of error
Two users of my add-on have reported it crashes Blender on their MacOS computer when running it's initial operator. This issue seems to only occur on very specific hardware combined with the MacOS operating system, as we have a lot of other MacOS users who do not have this crash occurring.

Exact steps for others to reproduce the error
It is not clear to me what exactly is causing the error. It seems MacOS specific, and the gpus of the two users both have the same amount of 2GB of VRAM.

Both the users describe the crash as happening when running the HG_START_CREATION operator in the HG_CREATION.py file that can be found in the attachments. This operator basically does the following:
-it imports several objects from an external file using libraries.load and subsequently linking those object to the scene
-it adds some custom properties to some of these objects
-it removes two particle systems from one of these objects
-it loads external images and sets them as the image for several TexImage nodes
-it deletes one node from one of the material node trees

As I'm not able to reproduce the crash myself, I have not been able to narrow down what part of this operator is causing the crash. Unfortunately, the MacOS crash reports also do not include a Python stacktrace

The crash log shows the following error codes:

Exception Type:        EXC_ARITHMETIC (SIGFPE)
Exception Codes:       EXC_I386_DIV (divide by zero)
Exception Note:        EXC_CORPSE_NOTIFY

Termination Signal:    Floating point exception: 8
Termination Reason:    Namespace SIGNAL, Code 0x8
Terminating Process:   exc handler [16093]

The above-mentioned operator doesn't do any arithmetic with divisions, so I really am not sure how it's causing this crash.

I would love to get any help or suggestions what direction I should be looking into for resolving this crash, as I'm currently quite unsure what to do about it.
I could imagine the low amount of VRAM (2gb) could be causing a problem when models are being imported by a script, but the add-on was able to run just fine on a very old windows laptop with no dedicated gpu.

I've attached a crash log supplied by one of the users below, with the permission of said user:

Event Timeline

Some extra information: One of the users who is experiencing the crash indicates that it doesn't crash on 2.83, it just seems to be crashing on his newer 2.92 version.

Some new information: A new user who is experiencing the crash has a 6GB VRAM card, thereby disproving our hypothesis of low VRAM being a correlation between the crashes.

When testing the code one section at a time by one of our users, it can go to line 54 in the Python file without crashing. The next testing section started at line 67 so I presume the origin of the crash is between these lines. I'm going to try to write this section with workaround methods of achieving the same thing and see if this perhaps doesn't trigger the crash.

Also, I should note that the users are using both MacOS Catalina and the newest Big Sur. Because MacOS updates GPU drivers with their OS updates one could rule out outdated GPU drivers being the culprit

Extra information: By one of our users testing the sections even further, it looks like the crash occurs in line 65, where the imported objects are linked to the scene.

for obj in data_to.objects:
    scene.collection.objects.link(obj)

I assume there is no alternative way to link imported objects to the scene? I'd really like to make a workaround version for our users until more is known about this bug, but I can't think of a way to circumvent this specific line.

The crash happens in the GPU driver after doing a draw call, so this is not related to your script or Blender, at least not directly. So there isn't much we can do in this case. This issue should be reported to the GPU driver vendor instead.