Arch Linux

Here also is a log of the crash:
https://gist.github.com/christian-heusel/fdeda83827c6608f6fce6f94003b4e5a

Maybe its also worth noting that I have the testing repositories enabled.

Yeah, can repro in a fresh VM (no [testing]). It seems perl is crashing...which might have to go upstream. But I'm not sure about your backtrace...it appears to contain all kinds of unrelated rust stuff. Why not just keep it simple like this?

$ coredumpctl gdb (then answer y when it asks "Enable debuginfod for this session?")
(gdb) set logging enabled
(gdb) bt (or bt full)

It seems to produce saner looking traces (attached).

BTW @gromit, it appears you have been editing the Wiki page at [1]. Removing the stuff about `coredumpctl gdb' seems like a regression. It would probably be easier for end-users to handle the simpler option as outlined above?

[1] https://wiki.archlinux.org/title/Debugging/Getting_traces

Thanks for reproducing the issue and also for creating a cleaner trace!

> But I'm not sure about your backtrace...it appears to contain all kinds of unrelated rust stuff. Why not just keep it simple like this?

Maybe the reason is that I used coredumpctl and used "thread apply all backtrace full" as described in [0] without thinking about it.

> which might have to go upstream.

I opened an Issue, see [1].

> BTW @gromit, it appears you have been editing the Wiki page at [1]. Removing the stuff about `coredumpctl gdb' seems like a regression. It would probably be easier for end-users to handle the simpler option as outlined above?

I dont remember actually removing anything, actually I just moved stuff around a bit in the article to highlight that using debuginfod is probably the easiest in creating traces with information (opposed to rebuilding stuff by hand). The article was also edited since, my longterm goal to get it also sorted out with the page about debuginfod[2].

[0] https://wiki.archlinux.org/title/Debugging/Getting_traces#Getting_the_trace
[1] https://github.com/shutter-project/shutter/issues/583
[2] https://wiki.archlinux.org/title/Debuginfod

Thanks for the report, the issue seems related to perl-glib-object-introspection 0.050-1

Reverting this one, the right click menu here works fine. Could you please temporarily downgrade the perl-glib-object-introspection package to 0.049-3 and test again?

also may be related

https://rt.cpan.org/Public/Bug/Display.html?id=147409
https://rt.cpan.org/Public/Bug/Display.html?id=148280

> Could you please temporarily downgrade the perl-glib-object-introspection package to 0.049-3 and test again?

When testing with 0.049-3 shutter does not start at all, but that might again be because of the testing repos.

the only perl related package in testing seems to be perl 5.36.1-1

by the way I'm pretty sure is related to perl-glib-object-introspection 0.050 and this bug https://rt.cpan.org/Public/Bug/Display.html?id=148280

let's give some days to the upstream to track the issue

The bug is fixed upstream at https://gitlab.gnome.org/GNOME/perl-glib-object-introspection/-/commit/eef3b1f8662bf76095987eeef41308094693cf3e around a month ago but they haven't released a new version yet. Maybe the changes can be patched into a perl-glib-object-introspection 0.050-2?

@Photon: indeed the patch fixes the bug, I patched the pkgbuild and created a MR for it ...
https://gitlab.archlinux.org/archlinux/packaging/packages/perl-glib-object-introspection/-/merge_requests/1

Maybe @muflone decides to wait for an upstream release, but since now some time has passed and they didnt release it might me worth to just use the backported patch :)

Great, thanks! I also think that the backport patch is a good idea! I commented, asking for a new release but there is no reply either: https://gitlab.gnome.org/GNOME/perl-glib-object-introspection/-/issues/4

fixed in perl-glib-object-introspection 0.050-2 by backporting the patch from master