Glimpse: Crash on startup due to segmentation fault on Arch Linux

[marvka]

Describe the bug

Glimpse crashes with a segmentation fault upon launching it on Arch Linux, apparently while trying to load the pagecurl plugin.

To Reproduce

Steps to reproduce the behavior:

1. Launch Glimpse on Arch (tried AUR and flatpak, both crash)
2. Image pops up loading plugins
3. Crashes halfway through startup

Expected behavior

It's supposed to start up without crashing.

Desktop (please complete the following information)

• OS: Arch Linux
• Version: latest, Kernel 5.5.9-arch1-2, with XFCE

Verbose Logs

Verbose log is quite long and mostly seems irrelevant, here's the potential interesting bits:

Gtk-Message: 18:59:10.970: Failed to load module "canberra-gtk-module"
Gtk-Message: 18:59:10.970: Failed to load module "canberra-gtk-module"
Gtk-Message: 18:59:12.157: Failed to load module "canberra-gtk-module"
Gtk-Message: 18:59:12.157: Failed to load module "canberra-gtk-module"

and

Querying plug-in: '/app/lib/glimpse/2.0/plug-ins/pagecurl/pagecurl'

(glimpse:2): GLib-GObject-CRITICAL **: 18:38:44.618: g_param_spec_internal: assertion 'is_valid_property_name (name)' failed
glimpse: fatal error: Segmentation fault

(pagecurl:88): LibGimpBase-WARNING **: 18:38:44.632: pagecurl: gimp_wire_read(): error

Complete log dump: https://gist.github.com/marvkal/d3120be318f693972f00a201a23a241d

[TrechNex]

I've tagged this to the 0.1.4. In the meantime, it may be worth experimenting to see if installing 64-bit and 32-bit versions of libcanberra yields any positive results. Much like GNU Image Manipulation Program we still use GTK2 instead of GTK3, so that's another reason things like this trip up.

It may also be worth getting in touch with the person who packaged the AUR to see if they have any insights. :)

If all else fails, I am actively working on creating a couple of Linux AppImages that might be of interest. I'm hoping to release those before the end of this month (March 2020)

[cristianovitorino]

I'm experiencing the exact same issue. Using the Flatpak package.

I've tried installing libcanberra libcanberra-pulse and lib32-libcanberra to no avail.

If all else fails, I am actively working on creating a couple of Linux AppImages that might be of interest. I'm hoping to release those before the end of this month (March 2020)

@TrechNex An AppImage would be really good! Please embed the update function, so we can update the package with the AppImageUpdate application.

flatpak run org.glimpse_editor.Glimpse
Gtk-Message: 20:00:31.693: Failed to load module "canberra-gtk-module"

(glimpse:2): Gtk-WARNING **: 20:00:31.904: Unable to locate theme engine in module_path: "murrine",

(glimpse:2): Gtk-WARNING **: 20:00:31.905: Unable to locate theme engine in module_path: "murrine",

(glimpse:2): Gtk-WARNING **: 20:00:31.906: Unable to locate theme engine in module_path: "murrine",

(glimpse:2): Gtk-WARNING **: 20:00:31.906: Unable to locate theme engine in module_path: "murrine",

(glimpse:2): Gtk-WARNING **: 20:00:31.906: Unable to locate theme engine in module_path: "murrine",

(glimpse:2): Gtk-WARNING **: 20:00:32.103: Theme directory 32/apps of theme Inverse-black-dark has no size field

Gtk-Message: 20:00:33.229: Failed to load module "canberra-gtk-module"

(glimpse:2): GLib-GObject-CRITICAL **: 20:00:35.031: g_param_spec_internal: assertion 'is_valid_property_name (name)' failed
glimpse: fatal error: Segmentation fault

(pagecurl:88): LibGimpBase-WARNING **: 20:00:35.045: pagecurl: gimp_wire_read(): error

[TrechNex]

Okay, if this isn't specific to one person's installation then that adds a renewed priority on the Linux AppImage.

(We had initially prioritised it because of Flathub's odd decision to no longer support 32-bit builds of any software, but it looks like a fully self-contained AppImage will be a good alternative for distributions where people are having problems)

[cristianovitorino]

(We had initially prioritised it because of Flathub's odd decision to no longer support 32-bit builds of any software, but it looks like a fully self-contained AppImage will be a good alternative for distributions where people are having problems)

Yeah, I think Flathub is nice, but it has it's quirks, and the updates are frenquent and always absolutely gargantuan.

AppImage is so much more convenient to my user point of view, specially if it has the update function embedded. Reminds me of how single apps are handled on macOS. download, drag to installation folder, done. And I think it's quite trivial to CI too?

Using the Open Build Service

Bundling your Travis CI builds as AppImages

[TrechNex]

Linking to #108

My plan is to adapt the great work @aferrero2707 did for the GNU Image Manipulation Program's AppImage

[hadess]

I have no idea why a crash that's likely a bug in the software is being linked to packaging the application as an appimage. The Flatpak from Flathub also crashes:
https://github.com/flathub/org.glimpse_editor.Glimpse/issues/2

The crasher is likely due to changes in glib which has become more stringent to what it accepts as signal parameter names.

Upstream/GIMP patch:
https://gitlab.gnome.org/GNOME/gimp/-/commit/1af8ad8905352de95bb827beb488aed8997cad71

[TrechNex]

@hadess all the information you just provided is new to us, so give us some time to look through this.

The reason we linked this to an alternative packaging mechanism fwiw is it seemed like the fastest deliverable fix based on the available information. Generally speaking if people report distro-specific problems we tend to assume it's a packaging or dependency problem until proven otherwise.

The information you're providing would probably count as "until proven otherwise". Do we know if this impacts Linux distributions that are not Arch or Arch-based?

[TrechNex]

I am particularly annoyed btw that we didn't make this change and now we have buggy behaviour.
See https://github.com/flathub/org.glimpse_editor.Glimpse/pull/1

[TrechNex]

cc @bochecha as it seems someone made a change on the Flathub repository without us knowing about it that broke things.

Our choices are basically:
a) Roll back the change made on Flathub
b) Apply the patch and re-issue the 0.1.2 release

Option "a" is my preference, and we can apply "b" for the 0.1.4 release that uses the newer Gnome runtime

[hadess]

cc @bochecha as it seems someone made a change on the Flathub repository without us knowing about it that broke things.

He's not going to be able to answer for a while. I've already asked about whether the change made on Flathub was actually tested. But that's not going to fix any combinations of glimpse + new glib on any other distributions or systems.

b) Apply the patch and re-issue the 0.1.2 release

Reusing the same version number? That's a no-no. Call it 0.1.2.1 if you want, but version numbers are supposed to be unique, otherwise how do you make out which is a the fixed and the unfixed 0.1.2?

[TrechNex]

My thoughts exactly re: re-issuing. As far as I'm concerned this change shouldn't have happened, and I'm reversing it.

Until @bochecha looks at the permissions scheme though there's nothing to stop them reverting it right back again. This is annoying because they can clearly see we have a beta branch which they left totally unchanged, and people are using the master branch in production.

[TrechNex]

Confirming that the version of Glimpse Image Editor on Flathub should now be back to using Platform version 3.34. Can @cristianovitorino and @marvkal confirm if it now works on their system when they next get the chance?

(In case you're running flatpak update, it may take an hour or two after I made this post for the changes to propagate across Flathub's mirrors)

[cristianovitorino]

@TrechNex Working as a charm for me, thank you. Tho the downloading process from Flathub was weird. I posted the details on the Matrix channel.

[TrechNex]

Yeah, it looks like their servers are struggling a bit at the moment! Hopefully the fix propagates to peoples' machines over the next few days as they run their usual flatpak update commands :)

[marvka]

Excellent, works for me as well now! Should we close the issue now?

[TrechNex]

Awesome! Yes, I'm closing this as a fixed bug for 0.1.2 :)

[hadess]

It's not a packaging bug though, it's a bug in Glimpse with newer versions of glib.

[TrechNex]

@hadess to clarify what I've done here.

340 - a bug was raised because the flatpak version of 0.1.2 was broken on Arch Linux. That is now resolved by rolling back a change that happened outside our normal development process.

341 - a new bug I've opened specifically to address the issue you raised so that we can upgrade to platform version 3.36 for the 0.1.4 release.

Both are categorized as "packaging" because they currently apply exclusively to Flatpak, and as part of the Flatpak packaging process we can apply the patch you supplied.

If the bug also turns out to be present in Snapcraft and/or AppImage, then it would need to be a direct code fix.

[TrechNex]

The reason I am cautious about applying patches directly to code that may not apply in every scenario is we then have to test it in every single form of packaging we provide (including Windows), so it is better to determine where the bug exists first then make the fix. :)

[hadess]

340 - a bug was raised because the flatpak version of 0.1.2 was broken on Arch Linux. That is now resolved by rolling back a change that happened outside our normal development process.

It's a report that it was broken in the Flatpak and in Arch Linux' AUR.

[TrechNex]

We do not maintain the Arch Linux AUR. However, that would be some early evidence that the bug could impact distribution maintainers we are providing distribution tarballs for.

Please continue this discussion on #341. That's the open ticket where I will be tracking progress on this bug.

[TrechNex]

Just updating that the patch has now been applied in development branch. I would be interested to know if the Arch Linux AUR now works!

(It's possible it doesn't as BABL and GEGL are no longer submodules and use a different build system, but if the way they've packaged it does its own thing then it might be fixed)

[cristianovitorino]

Just updating that the patch has now been applied in development branch. I would be interested to know if the Arch Linux AUR now works!

(It's possible it doesn't as BABL and GEGL are no longer submodules and use a different build system, but if the way they've packaged it does its own thing then it might be fixed)

The AUR version is absolutely outdated and broken. As I debugged on the Matrix channel. Not sure if this should be reopen tho, as Flathub is working normally now.

Glimpse crashed with a fatal error: fatal error: Segmentation fault

Glimpse version 2.10.12
git-describe: 65188b5fcb
C compiler:
    Using built-in specs.
    COLLECT_GCC=gcc
    COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/lto-wrapper
    Target: x86_64-pc-linux-gnu
    Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-pkgversion='Arch Linux 9.3.0-1' --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++,d --enable-shared --enable-threads=posix --with-system-zlib --with-isl --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object --enable-linker-build-id --enable-lto --enable-plugin --enable-install-libiberty --with-linker-hash-style=gnu --enable-gnu-indirect-function --enable-multilib --disable-werror --enable-checking=release --enable-default-pie --enable-default-ssp --enable-cet=auto gdc_include_dir=/usr/include/dlang/gdc
    Thread model: posix
    gcc version 9.3.0 (Arch Linux 9.3.0-1) 

using GEGL version 0.4.22 (compiled against version 0.4.22)
using GLib version 2.64.1 (compiled against version 2.64.1)
using GdkPixbuf version 2.40.0 (compiled against version 2.40.0)
using GTK+ version 2.24.32 (compiled against version 2.24.32)
using Pango version 1.44.7 (compiled against version 1.44.7)
using Fontconfig version 2.13.91 (compiled against version 2.13.91)
using Cairo version 1.17.3 (compiled against version 1.17.3)

fatal error: Segmentation fault

Stack trace:

/usr/lib/libgimpbase-2.0.so.0(gimp_stack_trace_print+0x3b8)[0x7fd699272398]
glimpse-0.1(+0xc94bf)[0x55f97f60f4bf]
glimpse-0.1(gimp_fatal_error+0x17)[0x55f97f60f917]
glimpse-0.1(+0xc9faa)[0x55f97f60ffaa]
/usr/lib/libpthread.so.0(+0x147ff)[0x7fd6987717ff]
glimpse-0.1(gimp_param_spec_layer_id+0x67)[0x55f97f9b0217]
glimpse-0.1(gimp_pdb_compat_param_spec+0x1cd)[0x55f97f8c43ed]
glimpse-0.1(gimp_plug_in_handle_message+0x122f)[0x55f97f8d14ff]
glimpse-0.1(gimp_plug_in_manager_call_query+0x1a3)[0x55f97f8e0323]
glimpse-0.1(gimp_plug_in_manager_restore+0x7c5)[0x55f97f8d7de5]
glimpse-0.1(+0x3b05fd)[0x55f97f8f65fd]
/usr/lib/libgobject-2.0.so.0(g_closure_invoke+0x1a9)[0x7fd698a4c619]
/usr/lib/libgobject-2.0.so.0(+0x1f0e7)[0x7fd698a2d0e7]
/usr/lib/libgobject-2.0.so.0(g_signal_emit_valist+0xcd8)[0x7fd698a30ab8]
/usr/lib/libgobject-2.0.so.0(g_signal_emit+0x8f)[0x7fd698a326af]
glimpse-0.1(gimp_restore+0x10b)[0x55f97f8f5aeb]
glimpse-0.1(app_run+0x4dd)[0x55f97f60ed9d]
glimpse-0.1(main+0x399)[0x55f97f60e4e9]
/usr/lib/libc.so.6(__libc_start_main+0xf2)[0x7fd6985be022]
glimpse-0.1(_start+0x2d)[0x55f97f60e67d]

[marvka]

The AUR PKGBUILD is using the glimpse-0-1 branch. If you edit the PKGBUILD and change it to source=("git+https://github.com/glimpse-editor/Glimpse") it works fine. The AUR package has been flagged as out of date since 2020-03-05. I'll comment on the AUR page as well and shoot the maintainer a message.

EDIT: I also manually updated the pkgver in my PKGBUILD but I reckon I don't need to do that since makepkg should update that automatically I think?

[TrechNex]

@marvkal using the tip of glimpse-0-1 is the correct behaviour because that's where we now merge & tag our stable builds.

What concerns me is the build didn't seem to have been re-run since December, so something else about it must've stopped it from happening.

It's good to hear that the patch applied in dev-g210 (the default branch) fixes the problem

[cristianovitorino]

@marvkal using the tip of glimpse-0-1 is the correct behaviour because that's where we now merge & tag our stable builds.

Well, not necessarily, the PKGBUILD is for glimpse-editor-git, which _usually_ - but not always - means the main master dev branch/bleeding edge for a lot of developers, and the PKGBUILD, in general, compiles from that place specifically and follow the build instructions. For stable releases PKGBUILD would be called something like glimpse-editor which would fetch a stable properly released tar.gz package for example, wherever that is hosted or released.

For example, the eovim package. The stable tar.gz is fetched from their releases source=("$pkgname-$pkgver.tar.gz::https://github.com/$_author/$pkgname/archive/v$pkgver.tar.gz"). From more than a year ago.

But eovim-git's PKGBUILD gets it from their dev master branch directly: source=("eovim-git::git+https://github.com/jeanguyomarch/eovim.git"), last updated 17 days ago.

That's not a rule or anything, just an emergent standard/practice of some sorts I recognize when dealing with AUR. Some people separate things like package-stable, package-git, package-bin, package-appimage, etc. _Hyper_ on AUR have such characteristics.

So, it's not so strange or wrong to have glimpse-editor-git fetch from default/dev/bleeding edge at all, it should be the default IMO. It all depends if developers follows the git branch naming conventions and if PKGBUILD builders want to respect that.

Maybe I'll learn PKGBUILD and give it a try. See if I can pull off a PKGBUILD from glimpse-0-1 and make a Glimpse stable PKGBUILD.

[TrechNex]

Fair enough in that case. I don't mind the AUR following the tip of our development branch because I kind of assumed it was doing that anyway before we started troubleshooting this bug :)

[cristianovitorino]

It seems the problem is deeper, and that, whetever it is might've been affecting the current PKGBUILD from Fabio Lolix.

I wanted to do a PKGBUILD from the stable branch tar.xz, and this problem arrived again. See #351 for details.

But it may not be worth the trouble maybe, as 0.1.4 is around the corner and the issue seems fixed by now?

[TrechNex]

Thank you for the investigation work on this. Let's keep discussion going on #351 as that's still an open ticket :)