Segmentation fault (core dumped) on Pop_OS 22.04 w/ kernel 6.12

[Jachimo]

Brief summary of issue

Attempting to start Shutter on my Pop_OS installation results in a "Segmentation fault (core dumped)" error.

I installed Shutter via APT; version reports as 0.99.2 Rev.1593.

shutter:
  Installed: 0.99.2-4
  Candidate: 0.99.2-4
  Version table:
 *** 0.99.2-4 500
        500 http://apt.pop-os.org/ubuntu jammy/universe amd64 Packages
        500 http://apt.pop-os.org/ubuntu jammy/universe i386 Packages
        100 /var/lib/dpkg/status

Steps to reproduce the issue

1. Install Shutter from Pop_OS repositories
2. Launch Shutter from a shell
3. See error output

Error output

See attached files, but I think the important error messages are the ones similar to this:

GLib-CRITICAL **: g_variant_type_copy: assertion 'g_variant_type_check (type)' failed at /usr/lib/x86_64-linux-gnu/perl5/5.34/Glib/Object/Introspection.pm line 67, <DATA> line 19.
 at /usr/bin/shutter line 334, <DATA> line 19.
	Shutter::App::STARTUP(Shutter::App=HASH(0x5e6bcba85bc0)) called at /usr/lib/x86_64-linux-gnu/perl5/5.34/Glib/Object/Introspection.pm line 67

There are a lot of other message lines, especially in the --debug output file, but it's the GLib-CRITICAL ones that I think are fatal. All of them seem to involve Introspection.pm in some way.

Extra information, such as Shutter version, display server in use (Xorg or Wayland), operating system and ideas for how to solve:

I'm not a Perl guy, so I'm not quite sure what's going on, but maybe it's an incompatibility with the new-ish 6.12 kernel that Pop_OS is running, and the accompanying glibc? If I have time, I will try to reboot this system into an older kernel (pretty sure I still have 6.8 hanging around) and see if the behavior can be replicated there. If I do that, I'll post an update here.

Uname string:
Linux gr8tr 6.12.10-76061203-generic #202412060638~1753385872~22.04~dc2e00d SMP PREEMPT_DYNAMIC Thu J x86_64 x86_64 x86_64 GNU/Linux

glibc version:

$ ldd --version
ldd (Ubuntu GLIBC 2.35-0ubuntu3.10) 2.35
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Roland McGrath and Ulrich Drepper.

Perl version:

$ perl --version

This is perl 5, version 34, subversion 0 (v5.34.0) built for x86_64-linux-gnu-thread-multi
(with 67 registered patches, see perl -V for more detail)

X11 info:

version number:    11.0
vendor string:    The X.Org Foundation
vendor release number:    12101004
X.Org version: 1.21.1.4

More information is in the xdpyinfo.out file, attached.

xdpyinfo.out.txt

shutter-error.txt
shutter-error_debug.txt

[Photon89]

Could you please test the latest release (https://github.com/shutter-project/shutter/releases/tag/v0.99.6)? Please install libmoo-perl as new dependency before testing. You can just unpack the tarball and launch Shutter from the unpacked folder, no installation steps are required.

[Jachimo]

I installed libmoo-perl and tried the version from the repos (0.99.2-4) just to see if it was a dependency issue; got the same result as above. Oh well, worth a try.

With the latest tarball, it does seem to work! Although there are still a lot of errors similar to this in the console:

GLib-CRITICAL **: g_variant_type_copy: assertion 'g_variant_type_check (type)' failed at /usr/lib/x86_64-linux-gnu/perl5/5.34/Glib/Object/Introspection.pm line 67, <DATA> line 19.
 at ./shutter line 550, <DATA> line 19.
	Shutter::App::STARTUP(Shutter::App=HASH(0x5e78ab9d2690)) called at /usr/lib/x86_64-linux-gnu/perl5/5.34/Glib/Object/Introspection.pm line 67
	Glib::Object::Introspection::__ANON__(Shutter::App=HASH(0x5e78ab9d2690)) called at ./shutter line 11101

Making me think that might not have been the critical issue in the earlier version, after all? I have attached the console log in case anyone would like to review it.

shutter-latest.txt

For now, I will use the tarball version, though. Thanks for the assistance!

[Jachimo]

Well, I seem to have spoken too quickly. The latest version of Shutter worked exactly once ... on the second time, and all subsequent launches, it dumps core just like the older version did.

@Photon89 can you reopen this issue? I don't have permissions to do it.

shutter-secondlaunch.txt

[Photon89]

That's quite interesting, looks like loading the settings file leads to the segfault. To test this hypothesis, could you please delete (or move) ~/.shutter and see whether this makes Shutter launch without segmentation fault?

[Jachimo]

I think you are on to something...

If I delete the ~/.shutter/ directory and then launch the newly-downloaded version (still in my ~/Downloads/ dir, specifically in ~/Downloads/shutter-0.99.6/bin), it will run once. I get a popup where it loads a bunch of plugins on first launch, then the application window opens, and I can take a screenshot or two. When I close the GUI, it seems to sort of hang in the terminal until I hit Ctrl-C, but that may be correct behavior (it's supposed to run in the background?).

Here's a log of that: shutter-fromDownloads.txt

If I try to run it again after I close it, it crashes. But I can delete ~/.shutter/ and it will load plugins and run again, no issues.

That behavior is all consistent with the theory about it being something about loading the settings file.

However ... when I thought Shutter was working, I copied the decompressed tarball dir from ~/Downloads to ~/.local/bin and then created a symlink from ~/.local/bin/shutter to the actual executable, so that I could launch it from my PATH. And that version never works at all, even when I delete the ~/.shutter/ directory.

See this log, which shows me deleting the settings dir and then running Shutter and it immediately fails: shutter-delSettings.txt

This is what I'm working with:

jachimo@gr8tr:~/.local/bin$ ll
drwxrwxr-x 3 jachimo jachimo 4096 Aug 17 17:24 ./
drwx------ 6 jachimo jachimo 4096 Aug 13 23:52 ../
-rwxrwxr-x 1 jachimo jachimo  221 Aug 13 23:52 pip*
-rwxrwxr-x 1 jachimo jachimo  221 Aug 13 23:52 pip3*
-rwxrwxr-x 1 jachimo jachimo  221 Aug 13 23:52 pip3.10*
lrwxrwxrwx 1 jachimo jachimo   26 Aug 17 17:24 shutter -> shutter-0.99.6/bin/shutter*
drwxrwxr-x 6 jachimo jachimo 4096 Mar  2 04:27 shutter-0.99.6/
[...]
jachimo@gr8tr:~/.local/bin$ 

I would not expect this to operate any differently than when I run Shutter from ~/Downloads/ and honestly I'm having trouble understanding how it even could be different. But yet... it doesn't behave the same way, and fails each and every time, while the exact same binary sitting in a different location works when I delete the settings directory.

jachimo@gr8tr:~$ sha256sum .local/bin/shutter-0.99.6/bin/shutter 
2f44899df382fd2cd11c40b115a8ccba770493cc0d19280aff7a9899caa09dff  .local/bin/shutter-0.99.6/bin/shutter
jachimo@gr8tr:~$ sha256sum Downloads/shutter-0.99.6/bin/shutter 
2f44899df382fd2cd11c40b115a8ccba770493cc0d19280aff7a9899caa09dff  Downloads/shutter-0.99.6/bin/shutter

Same binary, two different locations on the same machine, different behaviors, but only when the settings dir is not there. Weird!

[DarthGandalf]

that may be correct behavior (it's supposed to run in the background?).

Yes, it shows the tray icon which would bring the main window back, or even take screenshot directly from tray menu.

Or you can run shutter again in another terminal or via start menu, etc, and it'll show the main window.

then created a symlink from ~/.local/bin/shutter to the actual executable

That won't work: shutter searches its files in path relative to the executable: if the files are not in ../share/shutter/ (note the .. at the start), they won't be found.

[Photon89]

I think, we need a backtrace here, please see at #349 (comment) (and later comments) for instructions!

[Jachimo]

That won't work: shutter searches its files in path relative to the executable: if the files are not in ../share/shutter/ (note the .. at the start), they won't be found.

@DarthGandalf - I'm a bit confused, but I think this might be the source of the problem.

Is Shutter actually searching relative to the executable after resolving all symbolic links? Or is it searching relative to the calling path, which could be a symlink? (I.e. what in Bash would be "$0"?) The latter seems like it would be very fragile, and would break commonly-used stuff like Debian Alternatives, which makes heavy use of symlinks to provide shortcuts around the system.

Here's what I'm using to test:

jachimo@gr8tr:~/.local/bin$ tree
.
├── shutter -> shutter-0.99.6/bin/shutter
├── shutter-0.99.6
│   ├── bin
│   │   └── shutter
[...]
│   ├── share
│   │   └── shutter
│   │       └── resources
│   │           ├── license
│   │           ├── modules
[...]

If I run ~/.local/bin/shutter-0.99.6/bin/shutter, it works.

If I run ~/.local/bin/shutter, I get an error. (I guess because it's searching for files in ~/.local/share/shutter which doesn't exist?)

But based on your statement that Shutter searches for its files relative to the executable, this shouldn't happen: it's the same executable either way, located in a place where ../share/shutter/ is valid.

It's only if it's using the called path rather than the actual executable that I'd be getting this, and that seems like it's going to be very fragile. E.g. if I were to install Shutter into /usr/local/bin and /usr/local/share (which ought to work fine), but then create an alternative from the generic /bin/screenshot or /usr/bin/screenshot (a totally valid thing you can do), that would fail..?

It seems like the app shouldn't be using the called path to find resources that are specific to the installation path of the executable, no? Is that normal Perl behavior?

[Photon89]

Maybe we should concentrate on getting a debug log to figure out the actual issue regarding loading the settings file for the moment and get back to this discussion later? 😃