Bug 2252195

Created attachment 2002056 [details]
Backtraces of threads running when crash occurs

Created attachment 2002057 [details]
Output of cura --debug

Thanks for the report. I'm going to assume this is a mismatch between cura and cura-fdm-materials. Possibly could be resolved by upgrading to a more recent version fo cura.

Unfortunately, I did not have much time for this package recently :(

Thanks Miro.

Is there further information I can provide?  Alternative versions I can try?

I'm comfortable building from SRPMs, if that would help.

I'll try to prepare an updated RPM next week. Unfortunately, I am unable to do in sooner.

Could you please try cura from this copr repository?

https://copr.fedorainfracloud.org/coprs/churchyard/cura-5.4.0/


$ sudo dnf copr enable churchyard/cura-5.4.0 
$ sudo dnf upgrade cura

Thank you for the rebuild.  I have tried it, and the same crash happens.

The RPMs definitely came from your copr:

[root@xiaomao ~]# dnf install cura
Last metadata expiration check: 0:00:17 ago on Thu 07 Dec 2023 10:44:09.
Dependencies resolved.
==============================================================================================================================================================
 Package                            Architecture        Version                       Repository                                                         Size
==============================================================================================================================================================
Installing:
 cura                               noarch              1:5.4.0-1.fc38                copr:copr.fedorainfracloud.org:churchyard:cura-5.4.0               33 M
Upgrading:
 libarcus                           x86_64              5.3.0-1.fc38                  copr:copr.fedorainfracloud.org:churchyard:cura-5.4.0               45 k
 libsavitar                         x86_64              5.3.0-1.fc38                  copr:copr.fedorainfracloud.org:churchyard:cura-5.4.0               46 k
 python3-arcus                      x86_64              5.3.0-1.fc38                  copr:copr.fedorainfracloud.org:churchyard:cura-5.4.0               37 k
 python3-savitar                    x86_64              5.3.0-1.fc38                  copr:copr.fedorainfracloud.org:churchyard:cura-5.4.0               45 k
 python3-uranium                    noarch              5.4.0-1.fc38                  copr:copr.fedorainfracloud.org:churchyard:cura-5.4.0              993 k
Installing dependencies:
 CuraEngine                         x86_64              1:5.4.0-1.fc38                copr:copr.fedorainfracloud.org:churchyard:cura-5.4.0              1.1 M
 cura-fdm-materials                 noarch              5.4.0-1.fc38                  copr:copr.fedorainfracloud.org:churchyard:cura-5.4.0               74 k


The crash report says this is the crash message:

Traceback (most recent call last):
  File "/usr/lib/python3.11/site-packages/UM/Qt/ListModel.py", line 54, in data
    return self._items[index.row()][self._role_names[role].decode("utf-8")]
           ~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
KeyError: 'material_name'


And this is the call stack of the relevant thread:

  File "/usr/bin/cura", line 165 in exceptHook
  File "/usr/lib/python3.11/site-packages/UM/Qt/ListModel.py", line 115 in setItems
  File "/usr/lib/python3.11/site-packages/cura/Machines/Models/ExtrudersModel.py", line 234 in __updateExtruders
  File "/usr/lib/python3.11/site-packages/UM/Qt/QtApplication.py", line 416 in exec
  File "/usr/lib/python3.11/site-packages/cura/CuraApplication.py", line 899 in run
  File "/usr/bin/cura", line 239 in <module>

Because it's possible that something in my particular Cura config is causing the problem, I ran this:

find $HOME/.[a-zA-Z]* -type f -print0 | xargs -0 grep -w 'material_name' 

So I can say that "material_name" doesn't occur in any file within my "dot" dirs.

Is there a way I can run cura within gdb (or VSCode), put a breakpoint on ListModel.py and look at the state of the application before the crash happens?

You should be able to sudeo-edit-add breakpoint() and then execute /usr/bin/cura by your favorite tool.


Anyway, since I cannot reproduce the crash, I was wondering if you would be willing to share your ~/.config/cura and ~/.local/share/cura folders (even privately in case there is something private in it).

> You should be able to sudeo-edit-add breakpoint()

I don't know what sudeo-edit-add is (and neither it seems, does Google).

Do you mean edit /usr/bin/cura, and add breakpoint() somewhere?

Ok, so I have managed to load cura into VSCode, and I can set breakpoints and have it stop on breakpoints, even in code in /usr/lib/python3.11/site-packages.  So I can debug Python code.

CuraApplication.py has the line "from cura.Machines.Models.ExtrudersModel import ExtrudersModel", and breakpoints I set within the class-level code in ExtrudersModel in /usr/lib/python3.11/site-packages/cura/Machines/Models/ExtrudersModel.py get triggered when I do the import.  That's good.  However when I continue, all the start up messages happen, I get a splash screen, but this eventually disappears, and then I don't know what's happening.  There's no main app window, and no systray icon.

I can see that CuraApplication.run() gets called, and it executes right to the bottom, where it calls self.exec().  I'm guessing that starts the main event loop.  Control doesn't come back from there.

What I don't see when I'm running in the debugger, but would expect to, is calls to ExtrudersModel.__init__().  I can also confirm that CuraApplication.getExtrudersModel() is also not called.  

This also happens if I run Cura within VSCode but without debugging.

The last few lines when I run Cura in VSCode are:

2023-12-08 13:59:35,583 - DEBUG - [MainThread] cura.Machines.MachineErrorChecker._rescheduleCheck [164]: New error check scheduled.
2023-12-08 13:59:35,589 - INFO - [MainThread] cura.Machines.MachineErrorChecker._setResult [221]: Error check finished, result = False, time = 0.01s
2023-12-08 13:59:36,077 - DEBUG - [JobQueueWorker [1]] cura.Machines.ContainerTree.run [185]: All MachineNode loading completed

When I run Cura outside of VSCode, I get this:

...
2023-12-08 14:00:09,130 - DEBUG - [JobQueueWorker [1]] cura.Machines.ContainerTree.run [174]: Started background loading of MachineNodes
2023-12-08 14:00:09,140 - DEBUG - [MainThread] cura.Machines.MachineErrorChecker._rescheduleCheck [164]: New error check scheduled.
2023-12-08 14:00:09,145 - DEBUG - [MainThread] cura.Machines.Models.IntentSelectionModel._update [73]: Updating IntentSelectionModel.
2023-12-08 14:00:09,175 - DEBUG - [MainThread] cura.Machines.Models.CustomQualityProfilesDropDownMenuModel._update [33]: Updating CustomQualityProfilesDropDownMenuModel.
2023-12-08 14:00:09,194 - DEBUG - [MainThread] cura.Machines.Models.IntentSelectionModel._update [73]: Updating IntentSelectionModel.
2023-12-08 14:00:09,194 - DEBUG - [MainThread] cura.Machines.Models.IntentSelectionModel._update [73]: Updating IntentSelectionModel.
2023-12-08 14:00:09,198 - DEBUG - [MainThread] cura.Machines.Models.IntentSelectionModel._update [73]: Updating IntentSelectionModel.
2023-12-08 14:00:09,265 - INFO - [MainThread] cura.Machines.MachineErrorChecker._setResult [221]: Error check finished, result = False, time = 0.13s
2023-12-08 14:00:09,294 - DEBUG - [MainThread] cura.Machines.Models.CustomQualityProfilesDropDownMenuModel._update [33]: Updating CustomQualityProfilesDropDownMenuModel.
2023-12-08 14:00:09,631 - DEBUG - [JobQueueWorker [1]] cura.Machines.ContainerTree.run [185]: All MachineNode loading completed
2023-12-08 14:00:09,981 - DEBUG - [MainThread] UM.Qt.QtRenderer._initialize [211]: Support for Vertex Array Objects: True
2023-12-08 14:00:09,986 - DEBUG - [MainThread] UM.View.GL.OpenGL.__init__ [121]: Initialized OpenGL subsystems.
2023-12-08 14:00:09,987 - DEBUG - [MainThread] UM.View.GL.OpenGL.__init__ [122]: OpenGL Version:  4.6 (Core Profile) Mesa 23.1.9
2023-12-08 14:00:09,987 - DEBUG - [MainThread] UM.View.GL.OpenGL.__init__ [123]: OpenGL Vendor:   AMD
2023-12-08 14:00:09,988 - DEBUG - [MainThread] UM.View.GL.OpenGL.__init__ [124]: OpenGL Renderer: AMD Radeon Vega 8 Graphics (raven, LLVM 16.0.6, DRM 3.54, 6.5.11-200.fc38.x86_64)
2023-12-08 14:00:09,988 - DEBUG - [MainThread] UM.View.GL.OpenGL.__init__ [125]: GLSL Version:    4.60.0
2023-12-08 14:00:09,989 - DEBUG - [MainThread] UM.View.GL.ShaderProgram.load [61]: Loading [/usr/share/uranium/resources/shaders/default.shader]...
2023-12-08 14:00:09,992 - DEBUG - [MainThread] UM.View.GL.ShaderProgram.load [61]: Loading [/usr/share/uranium/resources/shaders/selection.shader]...
2023-12-08 14:00:09,994 - DEBUG - [MainThread] UM.View.GL.ShaderProgram.load [61]: Loading [/usr/share/uranium/resources/shaders/select_face.shader]...
2023-12-08 14:00:09,996 - DEBUG - [MainThread] UM.View.GL.ShaderProgram.load [61]: Loading [/usr/share/uranium/resources/shaders/default.shader]...
2023-12-08 14:00:09,997 - DEBUG - [MainThread] UM.View.GL.ShaderProgram.load [61]: Loading [/usr/share/uranium/resources/shaders/composite.shader]...
2023-12-08 14:00:10,000 - DEBUG - [MainThread] UM.View.GL.ShaderProgram.load [61]: Loading [/usr/bin/../share/cura/resources/shaders/overhang.shader]...
2023-12-08 14:00:10,002 - DEBUG - [MainThread] UM.View.GL.ShaderProgram.load [61]: Loading [/usr/bin/../share/cura/resources/shaders/striped.shader]...
2023-12-08 14:00:10,006 - DEBUG - [MainThread] UM.View.GL.ShaderProgram.load [61]: Loading [/usr/bin/../share/cura/resources/shaders/transparent_object.shader]...
2023-12-08 14:00:10,008 - DEBUG - [MainThread] UM.View.GL.ShaderProgram.load [61]: Loading [/usr/bin/../share/cura/resources/shaders/striped.shader]...
2023-12-08 14:00:10,011 - DEBUG - [MainThread] UM.View.GL.ShaderProgram.load [61]: Loading [/usr/bin/../share/cura/resources/shaders/xray.shader]...
2023-12-08 14:00:10,012 - DEBUG - [MainThread] UM.View.GL.ShaderProgram.load [61]: Loading [/usr/bin/../share/cura/resources/shaders/xray_composite.shader]...
2023-12-08 14:00:10,015 - DEBUG - [MainThread] UM.View.GL.ShaderProgram.load [61]: Loading [/usr/share/uranium/resources/shaders/default.shader]...
2023-12-08 14:00:10,016 - DEBUG - [MainThread] UM.View.GL.ShaderProgram.load [61]: Loading [/usr/bin/../share/cura/resources/shaders/grid.shader]...
2023-12-08 14:00:10,021 - DEBUG - [MainThread] UM.View.GL.ShaderProgram.load [61]: Loading [/usr/share/uranium/resources/shaders/platform.shader]...
2023-12-08 14:00:10,034 - DEBUG - [MainThread] UM.View.GL.ShaderProgram.load [61]: Loading [/usr/bin/../share/cura/resources/shaders/xray.shader]...
2023-12-08 14:00:10,444 - CRITICAL - [MainThread] cura.CrashHandler.__init__ [66]: An uncaught error has occurred!
2023-12-08 14:00:10,445 - CRITICAL - [MainThread] cura.CrashHandler.__init__ [69]: Traceback (most recent call last):
2023-12-08 14:00:10,445 - CRITICAL - [MainThread] cura.CrashHandler.__init__ [69]:   File "/usr/lib/python3.11/site-packages/UM/Qt/ListModel.py", line 54, in data
2023-12-08 14:00:10,445 - CRITICAL - [MainThread] cura.CrashHandler.__init__ [69]:     return self._items[index.row()][self._role_names[role].decode("utf-8")]
2023-12-08 14:00:10,445 - CRITICAL - [MainThread] cura.CrashHandler.__init__ [69]:            ~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2023-12-08 14:00:10,446 - CRITICAL - [MainThread] cura.CrashHandler.__init__ [69]: KeyError: 'material_name'


So I think I'm out of options for doing debugging, unless I start making mods to /usr/lib/python3.11/site-packages/cura/Machines/Models/ExtrudersModel.py.  Suggestions welcome.

> if you would be willing to share your ~/.config/cura and ~/.local/share/cura folders

I tarred up these folders and removed them.  Cura starts without crashing.

I'll do some more testing to see if I can isolate what's in my existing files that causes the crash.  (I should say again that this crash is being experienced by several people)

(In reply to Mitch Davis from comment #10)
> > You should be able to sudeo-edit-add breakpoint()
> 
> I don't know what sudeo-edit-add is (and neither it seems, does Google).
> 
> Do you mean edit /usr/bin/cura, and add breakpoint() somewhere?

I've meant sudo-edit-add, i.e. use sudo to edit the file and add the modification.


I was typing in a hurry, sorry.

Works if the option "categories_expanded" is removed from cura.cfg, but crashes again if "Build Plate Adhesion" settings are expanded.

I haven't used Cura in a while, could you please guide me step by step to expand the "Build Plate Adhesion" settings?

(In reply to Malte from comment #14)
> Works if the option "categories_expanded" is removed from cura.cfg, but
> crashes again if "Build Plate Adhesion" settings are expanded.

Can you confirm that your crash is on Cura startup?  Or is it when you're altering the settings?

(In reply to Miro Hrončok from comment #15)
> I haven't used Cura in a while, could you please guide me step by step to
> expand the "Build Plate Adhesion" settings?

1) Open Cura and add a new printer (In my case it's an Creality Ender 3 v2)
2) Expand the settings menu on the upper right side, where the print quality is shown
3) Search for the Build Plate Adhesion setting in the menu and expand it
4) Cura will crash

(In reply to Mitch Davis from comment #16)
> (In reply to Malte from comment #14)
> > Works if the option "categories_expanded" is removed from cura.cfg, but
> > crashes again if "Build Plate Adhesion" settings are expanded.
> 
> Can you confirm that your crash is on Cura startup?  Or is it when you're
> altering the settings?

Once the menu is expanded the setting is stored in the config and will also cause Cura to crash on startup.

(In reply to Malte from comment #17)
> 1) Open Cura and add a new printer (In my case it's an Creality Ender 3 v2)

I don't see Creality in the printers list. Anyway, I have other printers.

> 2) Expand the settings menu on the upper right side, where the print quality
> is shown

I found that thing.

> 3) Search for the Build Plate Adhesion setting in the menu and expand it

I see *Adhesion* on/off switch. In *Show Custom* I see *Build Plate Adhesion* section to expand.

When I expand it, a `KeyError: 'material_name'` crash report is shown immediately.
When starting CUra again, it crashes again on startup.



Thanks for the reproducer.

-----

In ~/.config/cura/5.4/cura.cfg [cura] section, there is this line:

categories_expanded = ;adhesion_extruder_nr;adhesion_type;brim_gap;brim_inside_margin;brim_line_count;brim_outside_only;brim_replaces_support;brim_smart_ordering;brim_width;extruder_prime_pos_x;extruder_prime_pos_y;layer_0_z_overlap;platform_adhesion;prime_blob_enable;raft_acceleration;raft_airgap;raft_base_acceleration;raft_base_extruder_nr;raft_base_fan_speed;raft_base_jerk;raft_base_line_spacing;raft_base_line_width;raft_base_speed;raft_base_thickness;raft_fan_speed;raft_interface_acceleration;raft_interface_extruder_nr;raft_interface_fan_speed;raft_interface_jerk;raft_interface_layers;raft_interface_line_spacing;raft_interface_line_width;raft_interface_speed;raft_interface_thickness;raft_jerk;raft_margin;raft_smoothing;raft_speed;raft_surface_acceleration;raft_surface_extruder_nr;raft_surface_fan_speed;raft_surface_jerk;raft_surface_layers;raft_surface_line_spacing;raft_surface_line_width;raft_surface_speed;raft_surface_thickness;skirt_brim_extruder_nr;skirt_brim_minimal_length;skirt_gap;skirt_height;skirt_line_count


Removing it makes Cura no longer crash on startup.

I think I found the cause: https://github.com/Ultimaker/Cura/pull/17642

For the record, I updated /usr/lib/python3.12/site-packages/UM/Qt/ListModel.py on my system and changed:

    def data(self, index, role):
        """Reimplemented from QAbstractListModel"""

        if not index.isValid():
            return QVariant()
        return self._items[index.row()][self._role_names[role].decode("utf-8")]

To do:

        try:
            return self._items[index.row()][self._role_names[role].decode("utf-8")]
        except KeyError:
            raise RuntimeError(self._items)

It contained 2 items:

[{'id': 'Prusa i3 Mk2 fdmextruder', 'name': 'Extruder', 'enabled': True, 'color': '#8cb219', 'index': 0, 'definition': 'prusa_i3_mk2_extruder_0', 'material': 'ABS', 'variant': 'empty', 'stack': <ExtruderStack 'Prusa i3 Mk2 fdmextruder' containers=[<InstContainer 'Prusa i3 Mk2 fdmextruder_user'>, <InstContainer 'empty_quality_changes'>, <InstContainer 'empty_intent'>, <InstContainer 'normal'>, <XmlMaterialProfile 'generic_abs_175' ('ABS') from base file 'generic_abs_175'>, <InstContainer 'empty_variant'>, <InstContainer 'Prusa i3 Mk2 fdmextruder_settings'>, <DefContainer 'prusa_i3_mk2_extruder_0'>]>, 'material_brand': 'Generic', 'color_name': 'Generic', 'material_type': 'ABS', 'material_name': 'ABS'}, {'id': '', 'name': 'Not overridden', 'enabled': True, 'color': 'transparent', 'index': -1, 'definition': '', 'material': '', 'variant': '', 'stack': None, 'material_brand': '', 'color_name': '', 'material_type': '', 'material_label': ''}]

When formatted nicely:

[
    {
        'id': 'Prusa i3 Mk2 fdmextruder',
        'name': 'Extruder',
        'enabled': True,
        'color': '#8cb219',
        'index': 0,
        'definition': 'prusa_i3_mk2_extruder_0',
        'material': 'ABS',
        'variant': 'empty',
        'stack': ...,
        'material_brand': 'Generic',
        'color_name': 'Generic',
        'material_type': 'ABS',
        'material_name': 'ABS'
    },
    {
        'id': '',
        'name': 'Not overridden',
        'enabled': True,
        'color': 'transparent',
        'index': -1,
        'definition': '',
        'material': '',
        'variant': '',
        'stack': None,
        'material_brand': '',
        'color_name': '',
        'material_type': '',
        'material_label': ''
    }
]


Made me look for 'Not overridden' in the code and I found the culprit in cura/Machines/Models/ExtrudersModel.py.

I applied the fix in https://copr.fedorainfracloud.org/coprs/churchyard/cura-5.4.0/

Could you please retest?

$ sudo dnf copr enable churchyard/cura-5.4.0  # if not already done
$ sudo dnf --refresh upgrade cura

The fixed build is cura-5.4.0-2.fc39.noarch (or similar on Fedora 38 and 40).

cura-1:5.4.0-2.fc38.noarch works for me, I no longer get a crash on startup.

Thank you so much Miro and Malte!

FEDORA-2023-4860df2ec3 has been submitted as an update to Fedora 40. https://bodhi.fedoraproject.org/updates/FEDORA-2023-4860df2ec3

FEDORA-2023-afedeac2c5 has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2023-afedeac2c5

FEDORA-2023-258f3e8ceb has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-258f3e8ceb

FEDORA-2023-4860df2ec3 has been pushed to the Fedora 40 stable repository.
If problem still persists, please make note of it in this bug report.

Now that the updates exist, I no longer plan to maintain the builds in the testing copr. I suggest you sudo rm '/etc/yum.repos.d/_copr:copr.fedorainfracloud.org:churchyard:cura-5.4.0.repo'

FEDORA-2023-afedeac2c5 has been pushed to the Fedora 39 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-afedeac2c5`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-afedeac2c5

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2023-258f3e8ceb has been pushed to the Fedora 38 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-258f3e8ceb`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-258f3e8ceb

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2023-afedeac2c5 has been pushed to the Fedora 39 stable repository.
If problem still persists, please make note of it in this bug report.

FEDORA-2023-258f3e8ceb has been pushed to the Fedora 38 stable repository.
If problem still persists, please make note of it in this bug report.