Python tag or Python node in Xpresso crash Cinema 4D

[SmetK]

@ferdinand Thanks for the reply. I'll keep that in mind.

[ferdinand]

Just to be clear: I did not want to imply that we do not want to help you. But we need a little bit more from you. I would suggest to try to upload the crash report again. What is even better, is when you tell me a date and time (and your timezone) when you did submit a crash report (or a unqiue message you have put into the crash message).

[SmetK]

@ferdinand I just now noticed that the file attached incorrectly. At the time of publication, it's 6:00 PM(time of crash cinema 5:57PM), October 18th, Vladivostok time (UTC+10 (GMT+10)). The program crashes on random seed values. Am I correct in understanding that I can't change material parameter values ​​using the Python tag?
_BugReport.txt

[ferdinand]

Hey @SmetK,

hm, weird, I could not find your submitted crash report. Neither when I search by date nor by Call_Stack_Thread_24992. But I did insert your crash report myself and below are the last lines of the stack trace for the crashing thread (this is being read bottom to top, i.e., SplitIntoNgons is where it crashed). I did resolve this for the build 2026_0_0_db12fb68d6ba_2004155263. Which is not unimportant information, as using a wrong build to resolve crash offsets can lead to wildly inaccurate results. You can find out the build you are using by opening the Help > About window and there right clicking the build number.

Call_Stack_Thread_24992
    c4d_objects.xdl64 = maxon::boolean::OutlineSplitter::SplitIntoNgons
    c4d_objects.xdl64 = maxon::boolean::OutlineSplitter::SplitOutline
    c4d_objects.xdl64 = maxon::boolean::CutObject::<lambda_0>::operator()
    ... internal API gibberish, nothing semantically relevant here ...
    c4d_objects.xdl64 = maxon::boolean::PreProcessInput
    c4d_objects.xdl64 = cinema::BooleanGenerator::GetVirtualObjects
    c4d_base.xdl64 = cinema::PluginObject::GetVirtualObjectsNew
    c4d_base.xdl64 = cinema::BaseObject::CreateVirtualObjects
    ... (more lines) ...

So, as already indicated by your bug_report.txt itself, this is crashing in one of major modules of Cinema 4D (c4d_objects.xdl64) and not one of our Python modules (python.xdl64 or python_vm.xdl64). So neither your direct Python code nor the Python VM are the culprit. But it could still be that you are indirectly causing the crash, by for example deleting a scene element off main thread. And SplitIntoNgons then tries to access that object and everything goes up in flames.

The crash happens while trying to build the output of the new Boolean object. I briefly talked with the dev of the new Booleans, and he said he did not see crash stack trace yet, so this is not a known bug. It seems to choke on some n-gon input in particular. Maybe this does ring a bell for you, in the context of what you are doing?

Your scene does not crash in my local Cinema 4D 2026.0 (Win) nor the one from the Booleans developer, are you sure you are using the most recent build? Maybe you could try to manually recrate one of your setups (i.e., without Python) and see if that crashes too? Without us being able to reproduce the crash, it will be impossible to help you. See our Support Procedures: Examples for how to report crashes in a more effective way.

Cheers,
Ferdinand

[SmetK]

@ferdinand Thank you very much for your reply. I currently have the latest version of the program (screenshot).

The program crashes when the cloner is in object mode (circle spline) with cubes placed inside a new Boolean and subtracted from the main geometry( 1st object under boolean).

Reproduction:
1. Open project in Cinema 4D.
2. I play the timeline and after a couple of seconds the program crashes.
3. I restart the program and the project. I remove the nested Boolean objects one by one (Sweep, Cube, and Cloner with Cubes).
4. Deleting the cloner in object mode (a spline circle) with cubes inside solves the crash problem.

Result:
1. Program crashes

Versions:
NOK 2026.0, Windows 11

[ferdinand]

Hey @SmetK,

Thank you for the reproduction steps, this makes it much easier for us. The added information is that you must play back the timeline. I am, however, still unable to reproduce your crash. But I am still using on Windows a very late beta version of the 2026.0.0 RC, I will try to squeeze in some time this week to install the actual customer RC. I also checked macOS, where I have already 2026_0_0_db12fb68d6ba_2004155263 installed, i.e., your build, and the build the crash report was resolved for, and nothing is crashing there either.

I also had a look at your scene setup and all in all this is all very tame, especially Python-wise; this should not crash. What is a bit iffy, is that you use both a Python tag and a (Python) Xpresso setup to set scene parameters, and have them both set to the same priority. But the worst this should be able to lead to is race conditions. But since you seem to be able to reproduce this reliably, while we cannot, I would ask you to:

1. Test if this also crashes when you (a) disable the Python tag, (b) disable the Python tag AND the Xpresso tag, and (c) if it still crashes if you only disable the Xpresso tag.
2. Test if this still crashes if your make the priority of the Python and Xpresso tag more verbose, i.e., set your Python tag to something like this:

Overall, this does not strike me as something that is Python induced, as all you do is set parameters.

Cheers,
Ferdinand

[SmetK]

@ferdinand Thanks again for your reply.
I've done everything you asked. A clear pattern has emerged: the program crashes when the geometry in the Boolean is modified.

• As soon as I remove the Python tag (which completely affects the geometry change) and one node in Xpresso that affects the geometry (the noise in the displace modifier), everything works correctly.

• If I leave only Xpresso with the node for changing the noise in the Displace modifier, the program crashes.

• If I remove the cloner in object mode from the new Boolean from the setup, the entire setup with its programming tags works correct.

• If I replace the new Boolean with a legacy Boolean and subtract the cloner(in the connect generator) from the main geometry , the entire setup works correctly, but the geometry is cut poorly.

• If I remove the automatic code, but animate the cloner's position and angle changes using the Vibrate tag, the program crashes during playback.

My conclusion:

1. The new Boolean breaks the program when, with random cloner positions and angles, the geometry is cut incorrectly (there were cases where the Boolean simply returned empty geometry), crashing the program.

2. Or the problem is with my computer, but I didn't have such problems before until the new Boolean was added to the setup.

[ferdinand]

Hey @SmetK,

Thank you for the added information; that is really helpful! I unfortunately did not find the time to try this again on Windows, but I'll try next week if I can reproduce your crash. But I am a bit doubtful that jumping from my late-late beta version to the customer RC will make any difference. I will post here an update when I found anything out.

There exists already a ticket for the crash report I uploaded for you, I will add your explanations there. But I have two questions:

• May I upload your example file into the ticket?
• May I share your file in our beta community, to see if anyone else can reproduce the crash?

Cheers,
Ferdinand

[SmetK]

@ferdinand Yes, of course you can. And thanks for the answers. I'll be waiting for news.

[ferdinand]

Hey @SmetK,

so I am back, and I have good and bad news

The bad news is that I could not reproduce the crash with your scene on my Win machine with 2026_0_0_db12fb68d6ba_2004155263. I today also asked the users in our beta forum, and multiple users could not reproduce it either.

The "good" news is that without me noticing, in the last days a similar crash report (it terminates into the exact same lines as yours) has been attached to the issue I created for your crash. This crash came from a Korean user on macOS and with this users scene I could reproduce your crash (I just got the same exact stack trace). The Korean user does not have any Python in his/her scene, just some Boolean setup not unsimilar to yours.

I have grouped everything and added some comments in your ticket, and will in moment briefly talk with the Boolean developer. Python might be here a component in your case (which so far no one go to crash), but there seems to be a base case which happens independently of Python. Which makes sense given how harmless your code is.

When you want to follow this case, I would recommend reaching out to end user support, feel free to mention the ticket ITEM#623378 [Python] Booleans crash when building output. When there is a fundamental development which impacts API users, I will post it here for all developers to see, but we should not let end user issues bleed into developer issues.

So, I do not have a super satisfying answer, but we can at least reproduce this, which increases the chances of this being fixed.

Cheers,
Ferdinand

[SmetK]

@ferdinand Thank you very much for your reply and responsiveness!