Add Constraint (with Targets) operator crashes Blender #133

New Issue

Triager-bot · 2026-04-12T15:18:19Z

Triager-bot commented

2026-04-12 15:18:19 +00:00

Original bug report: https://projects.blender.org/blender/blender/issues/157221

System Information
Operating system: Linux-6.19.8-200.fc43.x86_64-x86_64-with-glibc2.42 64 Bits, WAYLAND UI
Graphics card: AMD Radeon Graphics (RADV RENOIR) Advanced Micro Devices radv Mesa 25.3.6 Vulkan Backend

Blender Version
Broken: version: 5.2.0 Alpha, branch: main, commit date: Sat Apr 11 05:26:00 2026 +0200, hash: 8deaa11ab02b5904e01571012efe5fcddb45763e
Worked: 5.1.0

Short description of error
When trying to add a constraint to an object with the Add Constraint (with Targets) operator, Blender crashes with the following error:

../build_linux_lite/bin/blender() [0xe03dad]
../build_linux_lite/bin/blender() [0xe03e32]
../build_linux_lite/bin/blender() [0xa31075]
../build_linux_lite/bin/blender() [0x28b0d2b]
../build_linux_lite/bin/blender() [0x28b1c51]
../build_linux_lite/bin/blender() [0x14bc303]
../build_linux_lite/bin/blender() [0x148eae5]
../build_linux_lite/bin/blender() [0x148ef82]
../build_linux_lite/bin/blender() [0x149023e]
../build_linux_lite/bin/blender() [0x2d29000]
../build_linux_lite/bin/blender() [0x2d3d3e0]
../build_linux_lite/bin/blender() [0x14935bf]
../build_linux_lite/bin/blender() [0x149465d]
../build_linux_lite/bin/blender() [0x1495116]
../build_linux_lite/bin/blender() [0x1484110]
../build_linux_lite/bin/blender() [0x52eda7]
/lib64/libc.so.6(+0x35b5) [0x7f2cb7c105b5]
/lib64/libc.so.6(__libc_start_main+0x88) [0x7f2cb7c10668]
../build_linux_lite/bin/blender() [0x534735]
BLI_assert failed: source/blender/makesdna/DNA_ID.h:1384, id_cast_assert(), at 'src == nullptr || ((void)0, (ID_Type)(*((const short *)(src->name)))) == Dst::id_type'
[1]    3164032 IOT instruction (core dumped)  ../build_linux_lite/bin/blender

Here is a recording of the bug in action:

Exact steps for others to reproduce the error
N/A

Original bug report: https://projects.blender.org/blender/blender/issues/157221 **System Information** Operating system: Linux-6.19.8-200.fc43.x86_64-x86_64-with-glibc2.42 64 Bits, WAYLAND UI Graphics card: AMD Radeon Graphics (RADV RENOIR) Advanced Micro Devices radv Mesa 25.3.6 Vulkan Backend **Blender Version** Broken: version: 5.2.0 Alpha, branch: main, commit date: `Sat Apr 11 05:26:00 2026 +0200`, hash: `8deaa11ab02b5904e01571012efe5fcddb45763e` Worked: 5.1.0 **Short description of error** When trying to add a constraint to an object with the `Add Constraint (with Targets)` operator, Blender crashes with the following error: ``` ../build_linux_lite/bin/blender() [0xe03dad] ../build_linux_lite/bin/blender() [0xe03e32] ../build_linux_lite/bin/blender() [0xa31075] ../build_linux_lite/bin/blender() [0x28b0d2b] ../build_linux_lite/bin/blender() [0x28b1c51] ../build_linux_lite/bin/blender() [0x14bc303] ../build_linux_lite/bin/blender() [0x148eae5] ../build_linux_lite/bin/blender() [0x148ef82] ../build_linux_lite/bin/blender() [0x149023e] ../build_linux_lite/bin/blender() [0x2d29000] ../build_linux_lite/bin/blender() [0x2d3d3e0] ../build_linux_lite/bin/blender() [0x14935bf] ../build_linux_lite/bin/blender() [0x149465d] ../build_linux_lite/bin/blender() [0x1495116] ../build_linux_lite/bin/blender() [0x1484110] ../build_linux_lite/bin/blender() [0x52eda7] /lib64/libc.so.6(+0x35b5) [0x7f2cb7c105b5] /lib64/libc.so.6(__libc_start_main+0x88) [0x7f2cb7c10668] ../build_linux_lite/bin/blender() [0x534735] BLI_assert failed: source/blender/makesdna/DNA_ID.h:1384, id_cast_assert(), at 'src == nullptr || ((void)0, (ID_Type)(*((const short *)(src->name)))) == Dst::id_type' [1] 3164032 IOT instruction (core dumped) ../build_linux_lite/bin/blender ``` Here is a recording of the bug in action: <video src="attachments/c92537c3-5839-4891-8f7a-45b8e7af3465" title="add-constraint-crash.mp4" controls></video> **Exact steps for others to reproduce the error** N/A

add-constraint-crash.mp4

1.7 MiB

Triager-bot added the Status/Needs review label 2026-04-12 15:18:19 +00:00

Triager-bot commented

2026-04-12 15:18:49 +00:00

Report is clear

LLM Reasoning

Got it, let's see. The bug report has a clear title, describes the issue (crash when using Add Constraint operator), includes the error message and stack trace, mentions versions that worked vs broken, and even a video. But wait, the steps to reproduce are "N/A". Wait, but the question is about clarity of the text description and steps if present. The steps part is N/A, but does the rest make it clear? The short description says when trying to add constraint with targets, Blender crashes. The error message is there. So even though steps are N/A, the description is clear enough? Wait, no—wait, the user is asking if the bug report clearly describes the issue. Let's check: title is clear, body has system info (but we ignore that), version info, short description with crash and error, video link. The steps to reproduce are N/A, but maybe the video helps. But the question is about clarity of text description and steps if present. Since steps are not present (N/A), but the text description is clear: it says when trying to add constraint, Blender crashes, gives error. So does that clearly describe the issue? Yes, because even without steps, the problem is stated. Wait, but maybe the steps are missing, but the question says "if they are present". Since steps are N/A, we don't judge them. The text description is clear: what operator causes crash, the error. So answer is Yes? Wait, no—wait, let's recheck. The bug report has a title, short description with crash and error, video. The steps to reproduce are N/A, but maybe that's okay because the video is there. But the question is about clarity of text description and steps if present. Since steps are not present (N/A), we focus on text description. The text says "When trying to add a constraint... Blender crashes with error...". That's clear. So answer is Yes? Wait, but maybe the user thinks that without steps, it's unclear, but the question says ignore system info, and judge clarity of text description and steps if present. Since steps are N/A, we don't consider them. The text description is clear. So answer is Yes.

JSON Data

{
"llm_judgement": true,
"processing_time": 26.474451999999996
}

### Report is clear <details> <summary>LLM Reasoning</summary> Got it, let's see. The bug report has a clear title, describes the issue (crash when using Add Constraint operator), includes the error message and stack trace, mentions versions that worked vs broken, and even a video. But wait, the steps to reproduce are "N/A". Wait, but the question is about clarity of the text description and steps if present. The steps part is N/A, but does the rest make it clear? The short description says when trying to add constraint with targets, Blender crashes. The error message is there. So even though steps are N/A, the description is clear enough? Wait, no—wait, the user is asking if the bug report clearly describes the issue. Let's check: title is clear, body has system info (but we ignore that), version info, short description with crash and error, video link. The steps to reproduce are N/A, but maybe the video helps. But the question is about clarity of text description and steps if present. Since steps are not present (N/A), but the text description is clear: it says when trying to add constraint, Blender crashes, gives error. So does that clearly describe the issue? Yes, because even without steps, the problem is stated. Wait, but maybe the steps are missing, but the question says "if they are present". Since steps are N/A, we don't judge them. The text description is clear: what operator causes crash, the error. So answer is Yes? Wait, no—wait, let's recheck. The bug report has a title, short description with crash and error, video. The steps to reproduce are N/A, but maybe that's okay because the video is there. But the question is about clarity of text description and steps if present. Since steps are not present (N/A), we focus on text description. The text says "When trying to add a constraint... Blender crashes with error...". That's clear. So answer is Yes? Wait, but maybe the user thinks that without steps, it's unclear, but the question says ignore system info, and judge clarity of text description and steps if present. Since steps are N/A, we don't consider them. The text description is clear. So answer is Yes. </details> <details> <summary>JSON Data</summary> { "llm_judgement": true, "processing_time": 26.474451999999996 } </details>

Triager-bot commented

2026-04-12 15:19:02 +00:00

Report is specific

LLM Reasoning

Got it, let's analyze this bug report. The title is "Add Constraint (with Targets) operator crashes Blender". The body mentions a specific operator ("Add Constraint (with Targets)") and that when using it, Blender crashes. There's also a stack trace and a video recording. The steps to reproduce are about using that specific operator. So this is a specific issue because it's tied to a particular feature/operator in Blender. Wait, but let me check the definition: specific bug reports are about a specific issue (like crashing while using a specific feature). Generic would be vague like "crashing while rendering". Here, the crash happens when using the "Add Constraint (with Targets)" operator, which is a specific feature. So the answer should be 'Specific'.

JSON Data

{
"llm_judgement": true,
"processing_time": 12.246827999999999
}

### Report is specific <details> <summary>LLM Reasoning</summary> Got it, let's analyze this bug report. The title is "Add Constraint (with Targets) operator crashes Blender". The body mentions a specific operator ("Add Constraint (with Targets)") and that when using it, Blender crashes. There's also a stack trace and a video recording. The steps to reproduce are about using that specific operator. So this is a specific issue because it's tied to a particular feature/operator in Blender. Wait, but let me check the definition: specific bug reports are about a specific issue (like crashing while using a specific feature). Generic would be vague like "crashing while rendering". Here, the crash happens when using the "Add Constraint (with Targets)" operator, which is a specific feature. So the answer should be 'Specific'. </details> <details> <summary>JSON Data</summary> { "llm_judgement": true, "processing_time": 12.246827999999999 } </details>

Triager-bot commented

2026-04-12 15:19:41 +00:00

Report flagged as NOT a duplicate by LLM

Constraint to object crashes Blender

https://projects.blender.org/blender/blender/issues/148388

System Information
Operating system: Windows-10-10.0.26100-SP0 64 Bits
Graphics card: AMD Radeon(TM) 890M Graphics Advanced Micro Devices AMD proprietary driver 24.30.40.06 (LLPC) Vulkan Backend

Blender Version
Broken: version: 4.5.3 LTS, branch: blender-v4.5-release, commit date: 2025-09-08 12:46, hash: 67807e1800cc
Worked: (newest version of Blender that worked as expected)
Same error for 5.0 version as well only 4.3 worked properly for me.

Short description of error

If I add constraint to an object Blender crashes. I've noticed that if object is hidden sometimes it does not crash

Exact steps for others to reproduce the error

I created a simple cube can cube1. For cube I added [copy position/ rotation... might be others as well tested only these] constraint to cube1. And it instantly crashes

I attached Blender file that crashes on opening because it has constrain

LLM Reasoning

Got it, let's analyze the two bug reports. First, look at the descriptions and steps.

Bug report 1: The issue is when using "Add Constraint (with Targets)" operator, Blender crashes. The error log shows a BLI_assert failure related to ID casting. Steps are N/A, but the title mentions the specific operator.

Bug report 2: Adding a constraint (like copy position/rotation) to an object causes crash. Sometimes hiding the object prevents it. They attached a file that crashes on opening due to constraints.

Now, check if they're the same issue. Both involve Blender crashing when adding/constraining objects. But the first is about the "Add Constraint (with Targets)" operator, the second is general constraint addition. However, the core problem might be related to constraint handling. Wait, but the steps and context: report 1 has a specific operator, report 2 has general constraints. But maybe they're different? Wait, no—wait, the first report's error is about ID casting (DNA_ID.h), which could be related to how targets are handled. The second report's crash when adding constraint, possibly with hidden objects. Are these the same underlying issue?

Wait, but the question is if they're duplicates. Let's check the key points: both involve Blender crashing during constraint operations. But the first is a specific operator (Add Constraint with Targets), the second is general constraint addition (copy position etc.). However, maybe the root cause is similar, but are they the same issue? Wait, no—because the steps and context differ. Report 1's steps are N/A, report 2 has specific steps (create cube, add constraint). Also, report 1 mentions a specific operator, report 2 general constraints. So maybe not duplicates. Wait, but let's think again.

Wait, the first report's error is about ID casting failure when using Add Constraint with Targets. The second report's crash when adding any constraint (like copy position) to an object. Are these two different manifestations of the same bug? Or different bugs?

Alternatively, maybe they are the same because both involve constraint-related crashes. But the steps and context: report 1 has a specific operator, report 2 has general constraints. The error logs might be different, but the user is asking based on description and steps.

Wait, the first report's "Exact steps" is N/A, so we don't know the exact steps, but the title is about Add Constraint (with Targets). The second report's steps are creating a cube and adding a constraint. So maybe they're different. But let's check the error messages. Report 1 has a BLI_assert failure in DNA_ID.h, which is about ID type casting. Report 2 doesn't have an error log, just says it crashes when adding constraint.

Hmm. The question is whether they are the same issue. Since the steps and context differ (one specific operator, one general constraint), and the error logs are different (report 1 has a detailed assert, report 2 doesn't), I think they are not duplicates. So the answer is No.

JSON Data

{
"llm_judgement": false,
"processing_time": 37.309981,
"duplicate_report_number": "148388"
}

### Report flagged as NOT a duplicate by LLM <details> <summary>Constraint to object crashes Blender</summary> https://projects.blender.org/blender/blender/issues/148388 **System Information** Operating system: Windows-10-10.0.26100-SP0 64 Bits Graphics card: AMD Radeon(TM) 890M Graphics Advanced Micro Devices AMD proprietary driver 24.30.40.06 (LLPC) Vulkan Backend **Blender Version** Broken: version: 4.5.3 LTS, branch: blender-v4.5-release, commit date: 2025-09-08 12:46, hash: `67807e1800cc` Worked: (newest version of Blender that worked as expected) Same error for 5.0 version as well only 4.3 worked properly for me. **Short description of error** If I add constraint to an object Blender crashes. I've noticed that if object is hidden sometimes it does not crash **Exact steps for others to reproduce the error** I created a simple cube can cube1. For cube I added [copy position/ rotation... might be others as well tested only these] constraint to cube1. And it instantly crashes I attached Blender file that crashes on opening because it has constrain </details> <details> <summary>LLM Reasoning</summary> Got it, let's analyze the two bug reports. First, look at the descriptions and steps. Bug report 1: The issue is when using "Add Constraint (with Targets)" operator, Blender crashes. The error log shows a BLI_assert failure related to ID casting. Steps are N/A, but the title mentions the specific operator. Bug report 2: Adding a constraint (like copy position/rotation) to an object causes crash. Sometimes hiding the object prevents it. They attached a file that crashes on opening due to constraints. Now, check if they're the same issue. Both involve Blender crashing when adding/constraining objects. But the first is about the "Add Constraint (with Targets)" operator, the second is general constraint addition. However, the core problem might be related to constraint handling. Wait, but the steps and context: report 1 has a specific operator, report 2 has general constraints. But maybe they're different? Wait, no—wait, the first report's error is about ID casting (DNA_ID.h), which could be related to how targets are handled. The second report's crash when adding constraint, possibly with hidden objects. Are these the same underlying issue? Wait, but the question is if they're duplicates. Let's check the key points: both involve Blender crashing during constraint operations. But the first is a specific operator (Add Constraint with Targets), the second is general constraint addition (copy position etc.). However, maybe the root cause is similar, but are they the same issue? Wait, no—because the steps and context differ. Report 1's steps are N/A, report 2 has specific steps (create cube, add constraint). Also, report 1 mentions a specific operator, report 2 general constraints. So maybe not duplicates. Wait, but let's think again. Wait, the first report's error is about ID casting failure when using Add Constraint with Targets. The second report's crash when adding any constraint (like copy position) to an object. Are these two different manifestations of the same bug? Or different bugs? Alternatively, maybe they are the same because both involve constraint-related crashes. But the steps and context: report 1 has a specific operator, report 2 has general constraints. The error logs might be different, but the user is asking based on description and steps. Wait, the first report's "Exact steps" is N/A, so we don't know the exact steps, but the title is about Add Constraint (with Targets). The second report's steps are creating a cube and adding a constraint. So maybe they're different. But let's check the error messages. Report 1 has a BLI_assert failure in DNA_ID.h, which is about ID type casting. Report 2 doesn't have an error log, just says it crashes when adding constraint. Hmm. The question is whether they are the same issue. Since the steps and context differ (one specific operator, one general constraint), and the error logs are different (report 1 has a detailed assert, report 2 doesn't), I think they are not duplicates. So the answer is No. </details> <details> <summary>JSON Data</summary> { "llm_judgement": false, "processing_time": 37.309981, "duplicate_report_number": "148388" } </details>

Triager-bot commented

2026-04-12 15:20:34 +00:00

Report flagged as NOT a duplicate by LLM

Adding an action constraint to an object crashes Blender

https://projects.blender.org/blender/blender/issues/130897

System Information
Operating system: Linux-6.11.9-gentoo-x86_64-AMD_Ryzen_9_7950X_16-Core_Processor-with-glibc2.40 64 Bits, X11 UI
Graphics card: AMD Radeon RX 7900 XT (radeonsi, navi31, LLVM 18.1.8, DRM 3.59, 6.11.9-gentoo) AMD 4.6 (Core Profile) Mesa 24.2.7 Opengl Backend

Blender Version
Broken: Latest main (0de8ae80466ac8f4eee4846366cf3cce15f5367b)
Worked: d724ba1f248485e35ac7514c66d168241bc68112

Short description of error
When you add an action constraint to an object, Blender crashes.

Exact steps for others to reproduce the error
Starting with a fresh new default scene:

Select the default cube.
Go to its constraint properties in the properties editor.
Add an action constraint.

LLM Reasoning

Got it, let's analyze these two bug reports. First, look at the descriptions and steps.

Bug report 1 is about the "Add Constraint (with Targets)" operator crashing Blender. The error involves a BLI_assert failure related to ID casting. The steps are N/A, but the title mentions adding a constraint with targets.

Bug report 2 is about adding an action constraint causing a crash. The steps are specific: select cube, go to constraint properties, add action constraint.

Now, check if they're the same issue. Bug 1's operator is "Add Constraint (with Targets)" which might be a general way to add constraints, while bug 2 specifies "action constraint". But do they describe the same crash? Let's see: both are about adding a constraint leading to a crash. However, the steps in bug 2 are more specific (action constraint), and bug 1's steps are N/A but mentions the operator. Are these the same underlying issue?

Wait, the key is whether the "Add Constraint (with Targets)" operator includes adding an action constraint. If so, then maybe they're duplicates. But let's check the error messages. Bug 1 has a stack trace with BLI_assert, bug 2 just says it crashes when adding action constraint. The system info is different (Linux versions, UI, graphics card), but that doesn't matter for duplication. The main thing is if the issue is the same: adding a constraint (specifically action in bug 2) causes crash.

But bug 1's title is "Add Constraint (with Targets)" which could be any constraint, while bug 2 is specifically action. Are these two reports about the same problem? Let's see: if adding an action constraint via that operator causes the crash, then maybe yes. But the steps in bug 2 are more detailed. However, the question is whether they're duplicates based on description and steps.

Wait, bug 1's "Exact steps" are N/A, but bug 2 has specific steps. The descriptions: bug 1 says when trying to add a constraint with that operator, crash; bug 2 says adding an action constraint crashes. Are these the same? Maybe not, because one is general (any constraint via that operator) and the other is specific (action constraint). But maybe the "Add Constraint (with Targets)" operator includes adding action constraints, so when you use that operator to add an action constraint, it crashes. Then they could be duplicates.

But let's think: if bug 1 is about any constraint added via that operator crashing, and bug 2 is about action constraint specifically, but the underlying cause is the same (the operator has a bug when adding constraints), then maybe yes. But I need to check if the steps align. Bug 2's steps are selecting cube, going to constraint properties, adding action constraint. That's a specific way to add an action constraint, which might be using the "Add Constraint" button (which could be part of the "with Targets" operator? Or maybe not). Alternatively, maybe bug 1 is about a different operator.

Alternatively, maybe they are different because one is general and the other is specific. But the question is whether they're duplicates. Let's see: if both are about adding a constraint (any or action) causing crash, but the steps differ. However, the key is if the issue is the same. Since bug 2 specifies "action constraint" and bug 1 is general, maybe they are different. But wait, maybe the "Add Constraint (with Targets)" operator in bug 1 includes adding action constraints, so when you use that operator to add an action constraint, it crashes, which would make them duplicates.

But I'm not sure. Let's check the error messages. Bug 1 has a stack trace with BLI_assert, bug 2 doesn't have a stack trace but says it crashes. The system info is different, but that's not relevant for duplication. The main thing is if the issue is the same: adding a constraint (specifically action in bug 2) causes crash. If bug 1's operator includes adding action constraints, then yes. But maybe not. Alternatively, maybe they are different because one is about the operator and the other is about a specific constraint type.

Given that, I think the answer is No, because one is general (any constraint via operator) and the other is specific (action constraint). So they might be different issues. Therefore, the answer is No.

JSON Data

{
"llm_judgement": false,
"processing_time": 51.958215,
"duplicate_report_number": "130897"
}

### Report flagged as NOT a duplicate by LLM <details> <summary>Adding an action constraint to an object crashes Blender</summary> https://projects.blender.org/blender/blender/issues/130897 **System Information** Operating system: Linux-6.11.9-gentoo-x86_64-AMD_Ryzen_9_7950X_16-Core_Processor-with-glibc2.40 64 Bits, X11 UI Graphics card: AMD Radeon RX 7900 XT (radeonsi, navi31, LLVM 18.1.8, DRM 3.59, 6.11.9-gentoo) AMD 4.6 (Core Profile) Mesa 24.2.7 Opengl Backend **Blender Version** Broken: Latest main (0de8ae80466ac8f4eee4846366cf3cce15f5367b) Worked: d724ba1f248485e35ac7514c66d168241bc68112 **Short description of error** When you add an action constraint to an object, Blender crashes. **Exact steps for others to reproduce the error** Starting with a fresh new default scene: 1. Select the default cube. 2. Go to its constraint properties in the properties editor. 3. Add an action constraint. </details> <details> <summary>LLM Reasoning</summary> Got it, let's analyze these two bug reports. First, look at the descriptions and steps. Bug report 1 is about the "Add Constraint (with Targets)" operator crashing Blender. The error involves a BLI_assert failure related to ID casting. The steps are N/A, but the title mentions adding a constraint with targets. Bug report 2 is about adding an action constraint causing a crash. The steps are specific: select cube, go to constraint properties, add action constraint. Now, check if they're the same issue. Bug 1's operator is "Add Constraint (with Targets)" which might be a general way to add constraints, while bug 2 specifies "action constraint". But do they describe the same crash? Let's see: both are about adding a constraint leading to a crash. However, the steps in bug 2 are more specific (action constraint), and bug 1's steps are N/A but mentions the operator. Are these the same underlying issue? Wait, the key is whether the "Add Constraint (with Targets)" operator includes adding an action constraint. If so, then maybe they're duplicates. But let's check the error messages. Bug 1 has a stack trace with BLI_assert, bug 2 just says it crashes when adding action constraint. The system info is different (Linux versions, UI, graphics card), but that doesn't matter for duplication. The main thing is if the issue is the same: adding a constraint (specifically action in bug 2) causes crash. But bug 1's title is "Add Constraint (with Targets)" which could be any constraint, while bug 2 is specifically action. Are these two reports about the same problem? Let's see: if adding an action constraint via that operator causes the crash, then maybe yes. But the steps in bug 2 are more detailed. However, the question is whether they're duplicates based on description and steps. Wait, bug 1's "Exact steps" are N/A, but bug 2 has specific steps. The descriptions: bug 1 says when trying to add a constraint with that operator, crash; bug 2 says adding an action constraint crashes. Are these the same? Maybe not, because one is general (any constraint via that operator) and the other is specific (action constraint). But maybe the "Add Constraint (with Targets)" operator includes adding action constraints, so when you use that operator to add an action constraint, it crashes. Then they could be duplicates. But let's think: if bug 1 is about any constraint added via that operator crashing, and bug 2 is about action constraint specifically, but the underlying cause is the same (the operator has a bug when adding constraints), then maybe yes. But I need to check if the steps align. Bug 2's steps are selecting cube, going to constraint properties, adding action constraint. That's a specific way to add an action constraint, which might be using the "Add Constraint" button (which could be part of the "with Targets" operator? Or maybe not). Alternatively, maybe bug 1 is about a different operator. Alternatively, maybe they are different because one is general and the other is specific. But the question is whether they're duplicates. Let's see: if both are about adding a constraint (any or action) causing crash, but the steps differ. However, the key is if the issue is the same. Since bug 2 specifies "action constraint" and bug 1 is general, maybe they are different. But wait, maybe the "Add Constraint (with Targets)" operator in bug 1 includes adding action constraints, so when you use that operator to add an action constraint, it crashes, which would make them duplicates. But I'm not sure. Let's check the error messages. Bug 1 has a stack trace with BLI_assert, bug 2 doesn't have a stack trace but says it crashes. The system info is different, but that's not relevant for duplication. The main thing is if the issue is the same: adding a constraint (specifically action in bug 2) causes crash. If bug 1's operator includes adding action constraints, then yes. But maybe not. Alternatively, maybe they are different because one is about the operator and the other is about a specific constraint type. Given that, I think the answer is No, because one is general (any constraint via operator) and the other is specific (action constraint). So they might be different issues. Therefore, the answer is No. </details> <details> <summary>JSON Data</summary> { "llm_judgement": false, "processing_time": 51.958215, "duplicate_report_number": "130897" } </details>

Triager-bot commented

2026-04-12 15:20:48 +00:00

Report flagged as NOT a duplicate by LLM

Blender crashes when constraint-keys are moved in NLA

https://projects.blender.org/blender/blender/issues/17810

Group: current SVN version
Resolution: Fixed

%%%hi!
Whenever i try to move a constraint-key (in my case a copy-location-key) in the NLA-editor, blender crashes immediately. this is not the case when i move or change keys in the IPO-window.
to recreate it, here an example:

open blender with default scene
select camera
add copy-location-constraint with target "Cube" (or whatever)
add key
open NLA-editor
move constraint-key
BAM! blender crashes

this happens in linux64bit with 8800gts and osx 10.5.5 (MPB)

kind regards!

sebastian
%%%

LLM Reasoning

Got it, let's analyze the two bug reports. First, look at the descriptions and steps to reproduce.

Bug report 1 is about the "Add Constraint (with Targets)" operator crashing Blender. The steps aren't detailed, but the error is when adding a constraint with targets.

Bug report 2 is about moving a constraint-key in the NLA editor causing a crash. The steps are: open default scene, select camera, add copy-location-constraint, add key, open NLA-editor, move the key—then crash.

The first one is about adding the constraint (the operator), the second is about moving a key of an existing constraint in NLA. Different actions: one is adding, the other is modifying a key. So they're not the same issue. Therefore, the answer is No.

JSON Data

{
"llm_judgement": false,
"processing_time": 13.208363000000002,
"duplicate_report_number": "17810"
}

### Report flagged as NOT a duplicate by LLM <details> <summary>Blender crashes when constraint-keys are moved in NLA</summary> https://projects.blender.org/blender/blender/issues/17810 **Group**: current SVN version **Resolution**: Fixed %%%hi! Whenever i try to move a constraint-key (in my case a copy-location-key) in the NLA-editor, blender crashes immediately. this is not the case when i move or change keys in the IPO-window. to recreate it, here an example: - open blender with default scene - select camera - add copy-location-constraint with target "Cube" (or whatever) - add key - open NLA-editor - move constraint-key - BAM! blender crashes this happens in linux64bit with 8800gts and osx 10.5.5 (MPB) kind regards! sebastian %%% </details> <details> <summary>LLM Reasoning</summary> Got it, let's analyze the two bug reports. First, look at the descriptions and steps to reproduce. Bug report 1 is about the "Add Constraint (with Targets)" operator crashing Blender. The steps aren't detailed, but the error is when adding a constraint with targets. Bug report 2 is about moving a constraint-key in the NLA editor causing a crash. The steps are: open default scene, select camera, add copy-location-constraint, add key, open NLA-editor, move the key—then crash. The first one is about adding the constraint (the operator), the second is about moving a key of an existing constraint in NLA. Different actions: one is adding, the other is modifying a key. So they're not the same issue. Therefore, the answer is No. </details> <details> <summary>JSON Data</summary> { "llm_judgement": false, "processing_time": 13.208363000000002, "duplicate_report_number": "17810" } </details>

Triager-bot commented

2026-04-12 15:21:08 +00:00

Report flagged as NOT a duplicate by LLM

Crash on add-on registration

https://projects.blender.org/blender/blender/issues/156686

System Information
Operating system: Linux-6.18.20-gentoo-dist-x86_64-AMD_Ryzen_9_9950X3D_16-Core_Processor-with-glibc2.42 64 Bits, WAYLAND UI
Graphics card: NVIDIA RTX 6000 Ada Generation/PCIe/SSE2 NVIDIA Corporation 4.6.0 NVIDIA 595.58.03 Opengl Backend

Blender Version
Broken: version: 5.2.0 Alpha, branch: main, commit date: 2026-04-01 01:26, hash: 319b242a8a3f
Worked: yesterday's build

Short description of error

Backtrace:

#0  0x000055555577e755 in blender::ListBaseT<blender::IDProperty>::begin (this=0x60) at /usr/src/debug/media-gfx/blender-9999/blender-9999/source/blender/makesdna/DNA_listBase.h:55
#1  0x0000555559e2232b in blender::ed::geometry::create_inputs_srna (properties=..., r_generated=...) at /usr/src/debug/media-gfx/blender-9999/blender-9999/source/blender/editors/geometry/node_group_operator.cc:1387
#2  0x0000555559e226e3 in blender::ed::geometry::register_node_tool (ot=0x7ff7770f3758, type_data_ptr=std::unique_ptr<blender::ed::geometry::OperatorTypeData> = {...})
    at /usr/src/debug/media-gfx/blender-9999/blender-9999/source/blender/editors/geometry/node_group_operator.cc:1445
#3  0x0000555559e23337 in operator() (__closure=0x0, ot=0x7ff7770f3758, user_data=0x7ff79852e158) at /usr/src/debug/media-gfx/blender-9999/blender-9999/source/blender/editors/geometry/node_group_operator.cc:1660
#4  0x0000555559e23369 in _FUN () at /usr/src/debug/media-gfx/blender-9999/blender-9999/source/blender/editors/geometry/node_group_operator.cc:1661
#5  0x00005555574d60fa in blender::WM_operatortype_append_ptr (opfunc=0x555559e23340 <_FUN(blender::wmOperatorType*, void*)>, userdata=0x7ff79852e158)
    at /usr/src/debug/media-gfx/blender-9999/blender-9999/source/blender/windowmanager/intern/wm_operator_type.cc:159
#6  0x0000555559e23964 in blender::ed::geometry::register_node_group_operators (C=...) at /usr/src/debug/media-gfx/blender-9999/blender-9999/source/blender/editors/geometry/node_group_operator.cc:1658
#7  0x00005555574989e0 in blender::wm_event_do_notifiers (C=0x7fffe3d99488) at /usr/src/debug/media-gfx/blender-9999/blender-9999/source/blender/windowmanager/intern/wm_event_system.cc:647
#8  0x000055555748f472 in blender::WM_main (C=0x7fffe3d99488) at /usr/src/debug/media-gfx/blender-9999/blender-9999/source/blender/windowmanager/intern/wm.cc:611
#9  0x00005555555e8287 in main (argc=1, argv=0x7fffffffe098) at /usr/src/debug/media-gfx/blender-9999/blender-9999/source/creator/creator.cc:657

Exact steps for others to reproduce the error

Download and enable the Brushstroke Tools extension.

LLM Reasoning

Got it, let's analyze these two bug reports. First, look at the descriptions and steps.

Bug report 1 is about the "Add Constraint (with Targets)" operator crashing Blender. The error involves a BLI_assert failure related to ID casting. The steps are N/A, but the crash happens when using that specific operator.

Bug report 2 is about a crash on add-on registration, specifically with the Brushstroke Tools extension. The backtrace shows issues in node group operator registration, not related to constraints or the same operator as report 1.

The key parts: Report 1's issue is with adding constraints (operator), Report 2's is add-on registration (Brushstroke Tools). Different contexts, different causes. So they're not the same issue.

JSON Data

{
"llm_judgement": false,
"processing_time": 18.73895,
"duplicate_report_number": "156686"
}

### Report flagged as NOT a duplicate by LLM <details> <summary>Crash on add-on registration</summary> https://projects.blender.org/blender/blender/issues/156686 **System Information** Operating system: Linux-6.18.20-gentoo-dist-x86_64-AMD_Ryzen_9_9950X3D_16-Core_Processor-with-glibc2.42 64 Bits, WAYLAND UI Graphics card: NVIDIA RTX 6000 Ada Generation/PCIe/SSE2 NVIDIA Corporation 4.6.0 NVIDIA 595.58.03 Opengl Backend **Blender Version** Broken: version: 5.2.0 Alpha, branch: main, commit date: 2026-04-01 01:26, hash: `319b242a8a3f` Worked: yesterday's build **Short description of error** Backtrace: ``` #0 0x000055555577e755 in blender::ListBaseT<blender::IDProperty>::begin (this=0x60) at /usr/src/debug/media-gfx/blender-9999/blender-9999/source/blender/makesdna/DNA_listBase.h:55 #1 0x0000555559e2232b in blender::ed::geometry::create_inputs_srna (properties=..., r_generated=...) at /usr/src/debug/media-gfx/blender-9999/blender-9999/source/blender/editors/geometry/node_group_operator.cc:1387 #2 0x0000555559e226e3 in blender::ed::geometry::register_node_tool (ot=0x7ff7770f3758, type_data_ptr=std::unique_ptr<blender::ed::geometry::OperatorTypeData> = {...}) at /usr/src/debug/media-gfx/blender-9999/blender-9999/source/blender/editors/geometry/node_group_operator.cc:1445 #3 0x0000555559e23337 in operator() (__closure=0x0, ot=0x7ff7770f3758, user_data=0x7ff79852e158) at /usr/src/debug/media-gfx/blender-9999/blender-9999/source/blender/editors/geometry/node_group_operator.cc:1660 #4 0x0000555559e23369 in _FUN () at /usr/src/debug/media-gfx/blender-9999/blender-9999/source/blender/editors/geometry/node_group_operator.cc:1661 #5 0x00005555574d60fa in blender::WM_operatortype_append_ptr (opfunc=0x555559e23340 <_FUN(blender::wmOperatorType*, void*)>, userdata=0x7ff79852e158) at /usr/src/debug/media-gfx/blender-9999/blender-9999/source/blender/windowmanager/intern/wm_operator_type.cc:159 #6 0x0000555559e23964 in blender::ed::geometry::register_node_group_operators (C=...) at /usr/src/debug/media-gfx/blender-9999/blender-9999/source/blender/editors/geometry/node_group_operator.cc:1658 #7 0x00005555574989e0 in blender::wm_event_do_notifiers (C=0x7fffe3d99488) at /usr/src/debug/media-gfx/blender-9999/blender-9999/source/blender/windowmanager/intern/wm_event_system.cc:647 #8 0x000055555748f472 in blender::WM_main (C=0x7fffe3d99488) at /usr/src/debug/media-gfx/blender-9999/blender-9999/source/blender/windowmanager/intern/wm.cc:611 #9 0x00005555555e8287 in main (argc=1, argv=0x7fffffffe098) at /usr/src/debug/media-gfx/blender-9999/blender-9999/source/creator/creator.cc:657 ``` **Exact steps for others to reproduce the error** Download and enable the [Brushstroke Tools extension](https://extensions.blender.org/add-ons/brushstroke-tools/). </details> <details> <summary>LLM Reasoning</summary> Got it, let's analyze these two bug reports. First, look at the descriptions and steps. Bug report 1 is about the "Add Constraint (with Targets)" operator crashing Blender. The error involves a BLI_assert failure related to ID casting. The steps are N/A, but the crash happens when using that specific operator. Bug report 2 is about a crash on add-on registration, specifically with the Brushstroke Tools extension. The backtrace shows issues in node group operator registration, not related to constraints or the same operator as report 1. The key parts: Report 1's issue is with adding constraints (operator), Report 2's is add-on registration (Brushstroke Tools). Different contexts, different causes. So they're not the same issue. </details> <details> <summary>JSON Data</summary> { "llm_judgement": false, "processing_time": 18.73895, "duplicate_report_number": "156686" } </details>

Triager-bot commented

2026-04-12 15:21:24 +00:00

Report flagged as NOT a duplicate by LLM

Crash 2.45 in constraints

https://projects.blender.org/blender/blender/issues/7469

Group: V 2.45 release
Resolution: Investigate
Category: Animation system

%%%Got the following when trying to do something with constraints (delete the seconf of two?)

./blenderguessing './blender' == '/home/martin/blender/./blender'

Compiled with Python version 2.5.
Checking for installed Python... got it!
Memoryblock free: attempt to free illegal pointer
Segmentation fault

uname -a

Linux localhost.localdomain 2.6.22.5-1076.ez.fc7 #1 SMP Sat Sep 15 18:49:08 BST 2007 x86_64 x86_64 x86_64 GNU/Linux

./blender -v

guessing './blender' == '/home/martin/blender/./blender'
Blender 2.45 (sub 0) Build

%%%

LLM Reasoning

Got it, let's analyze the two bug reports. First, look at the key sections: description and steps to reproduce.

Bug report 1 is about the "Add Constraint (with Targets)" operator crashing Blender in version 5.2.0 Alpha. The error is a BLI_assert failure related to ID casting. Steps to reproduce are N/A, but the issue is specific to that operator.

Bug report 2 is about a crash in constraints in Blender 2.45, with a segmentation fault and memory block free error when doing something with constraints (maybe deleting one). The context is older version (2.45) vs 5.2.0 Alpha. The error types are different: BLI_assert vs segmentation fault/memory issue. Also, the operator mentioned in report 1 isn't referenced in report 2. The steps and environments are different too—report 1 has a specific operator, report 2 is vague about "something with constraints".

So they don't seem to be the same issue. Therefore, the answer is No.

JSON Data

{
"llm_judgement": false,
"processing_time": 15.84891,
"duplicate_report_number": "7469"
}

### Report flagged as NOT a duplicate by LLM <details> <summary>Crash 2.45 in constraints</summary> https://projects.blender.org/blender/blender/issues/7469 **Group**: V 2.45 release **Resolution**: Investigate **Category**: Animation system %%%Got the following when trying to do something with constraints (delete the seconf of two?) > ./blenderguessing './blender' == '/home/martin/blender/./blender' Compiled with Python version 2.5. Checking for installed Python... got it! Memoryblock free: attempt to free illegal pointer Segmentation fault > uname -a Linux localhost.localdomain 2.6.22.5-1076.ez.fc7 #1 SMP Sat Sep 15 18:49:08 BST 2007 x86_64 x86_64 x86_64 GNU/Linux > ./blender -v guessing './blender' == '/home/martin/blender/./blender' Blender 2.45 (sub 0) Build %%% </details> <details> <summary>LLM Reasoning</summary> Got it, let's analyze the two bug reports. First, look at the key sections: description and steps to reproduce. Bug report 1 is about the "Add Constraint (with Targets)" operator crashing Blender in version 5.2.0 Alpha. The error is a BLI_assert failure related to ID casting. Steps to reproduce are N/A, but the issue is specific to that operator. Bug report 2 is about a crash in constraints in Blender 2.45, with a segmentation fault and memory block free error when doing something with constraints (maybe deleting one). The context is older version (2.45) vs 5.2.0 Alpha. The error types are different: BLI_assert vs segmentation fault/memory issue. Also, the operator mentioned in report 1 isn't referenced in report 2. The steps and environments are different too—report 1 has a specific operator, report 2 is vague about "something with constraints". So they don't seem to be the same issue. Therefore, the answer is No. </details> <details> <summary>JSON Data</summary> { "llm_judgement": false, "processing_time": 15.84891, "duplicate_report_number": "7469" } </details>

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: Triager-bot/test#133

Add Constraint (with Targets) operator crashes Blender #133

Report is clear

Report is specific

Report flagged as NOT a duplicate by LLM

Report flagged as NOT a duplicate by LLM

Report flagged as NOT a duplicate by LLM

Report flagged as NOT a duplicate by LLM

Report flagged as NOT a duplicate by LLM

`Add Constraint (with Targets)` operator crashes Blender #133