Segfault with older glib

I’ve been working on snapping fwupdtool and have encountered something odd. During cleanup it segfaults. The same thing doesn’t segfault when using Ubuntu 18.04 userspace outside of a snap. So I’m guessing glib bug, but I’m really baffled the right way to get a newer glib into the snap.

#1  0x00007fbcf2f5fd9a in g_object_unref () from /snap/fwupdtool/x3/usr/lib/fwupd/../x86_64-linux-gnu/libgobject-2.0.so.0
#2  0x00000000004231df in fu_device_list_item_free (item=0x12888c0) at ../src/fu-device-list.c:534
#3  0x00007fbcf2c4f5ab in g_ptr_array_foreach () from /snap/fwupdtool/x3/usr/lib/fwupd/../../../lib/x86_64-linux-gnu/libglib-2.0.so.0
#4  0x00007fbcf2c4f640 in ?? () from /snap/fwupdtool/x3/usr/lib/fwupd/../../../lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x000000000042334f in fu_device_list_finalize (obj=0x127b480) at ../src/fu-device-list.c:572
#6  0x00007fbcf2f5fd9a in g_object_unref () from /snap/fwupdtool/x3/usr/lib/fwupd/../x86_64-linux-gnu/libgobject-2.0.so.0
#7  0x000000000041e06a in fu_engine_finalize (obj=0x1281820) at ../src/fu-engine.c:3441
#8  0x00007fbcf2f5fd9a in g_object_unref () from /snap/fwupdtool/x3/usr/lib/fwupd/../x86_64-linux-gnu/libgobject-2.0.so.0
#9  0x000000000040e487 in fu_util_private_free (priv=0x1279a50) at ../src/fu-tool.c:206
#10 0x000000000040e52f in glib_autoptr_cleanup_FuUtilPrivate (_ptr=0x7fffdb996c80) at ../src/fu-tool.c:220
#11 0x00000000004101af in main (argc=2, argv=0x7fffdb996ef8) at ../src/fu-tool.c:690

Can someone please advise how i’m supposed to do that?
My snapcraft.yaml is here:
https://github.com/hughsie/fwupd/blob/master/contrib/snap/snapcraft.yaml

The file I linked has been moved upstream in a recent PR.

I did manage to build with a newer glib (just with lots of hackery in stage: and adding an extra part) but still segfaults.

What else is snapd doing that could cause this behavior?

It’s possible that your app is making a system call that is restricted by the seccomp filter applied to your snap. Have a read of the “Debugging” section of the following post:

In particular, looking for audit messages in the log, and decoding those messages to a system call with scmp_sys_resolver. If this is what’s happening, then it might indicate an extra interface you need to plug.

Thanks for the feedback. Unfortunately I’m already running in classic mode with this snap (so as far as I can tell these particular confinement debug tips don’t apply).

Just FYI this segfault ended up not being related to snap but rather to a problem that reproduced more easily in a snap environment.