This useful short tutorial on creating a Snap from a deb, causes a segmentation fault when I try to run snapcraft. The same happens with the application I am developing. Within an LXD container I get more information:
Segmentation fault Failed to run 'override-pull': Exit code was 139.
There are several similar reports about segmentation faults, but the answers seem too specific to be of any help to me. I have only found one about the second error and it wasn’t relevant.
(Ubuntu Budgie 8.10)
A year is a long time in snapcraft, and that tutorial is over 2 years old, and some of what it details may have changed or may no longer be appropriate.
May I see the yaml you’re working with, or some detail of what you’re snapping? I think that’ll help us help you.
@popey Certainly.
snapcraft.yaml:
version: '0.1'
summary: Free Lemmings(TM) clone
description: |
Pingus is a free clone of the popular Lemmings game.
|
Your goal is to guide a horde of penguins through a world full of obstacles
and penguin traps to safety. Although penguins (unlike lemmings) are rather
smart, they sometimes lack the necessary overview and now rely on you to
save them.
grade: devel
confinement: devmode
parts:
archives:
plugin: nil
stage-packages:
- libc6 #Not in article
- pingus
env:
plugin: dump
organize:
pingus.wrapper: usr/bin/pingus
apps:
pingus:
command: pingus
pingus.wrapper:
exec $SNAP/usr/lib/games/pingus/pingus --datadir $SNAP/usr/share/games/pingus/data $@
There might be more error above your line here. Please post more of your build log or a link to a pastebin of it. For a start we don’t know what was happening when you hit the segmentation fault other than snapcraft was trying to pull something.
As an aside, you don’t have any source: lines in your yaml so everything will default to . meaning the location of the directory containing the snap folder where snapcraft.yaml lives. It’s best to be explicit about source locations to prevent any confusion.
I’ve been getting similar errors in various circumstances in the last 2 weeks or so. In my case it was with build stages using cmake, for snaps that had previously been building without issue.
In my case it was only showing up in cleanbuild runs, but today (on my Ubuntu 16.04 system) it started showing up with regular snapcraft calls, using apt-installed snapcraft (so, 2.43.1).
I’ve previously experienced it with snapcraft 3.1 and 3.1.1 snaps running inside LXD containers:
Note, in that report I note a -11 exit status, but I’ve also experienced 139, depending on what part is being built.
It occurs with snapcraft cleanbuild --debug (ie not running the Snap). The Snap still gets built and installed, but doesn’t run. I’ve been trying to build two different Snaps, with and without LXD.
There’s a lot of output, this is the end of it:
Fetched 6882 B in 0s (0 B/s)
Get:1 libsensors4_3.4.0-2_amd64.deb [28.4 kB]
Fetched 28.4 kB in 0s (0 B/s)
Get:1 libsamplerate0_0.1.8-8_amd64.deb [937 kB]
Fetched 937 kB in 0s (0 B/s)
Get:1 libxcb-dri3-0_1.11.1-1ubuntu1_amd64.deb [5218 B]
Fetched 5218 B in 0s (0 B/s)
Get:1 libpng12-0_1.2.54-1ubuntu1.1_amd64.deb [116 kB]
Fetched 116 kB in 0s (0 B/s)
Get:1 libglib2.0-0_2.48.2-0ubuntu4.1_amd64.deb [1120 kB]
Fetched 1120 kB in 0s (0 B/s)
Get:1 libx11-xcb1_1.6.3-1ubuntu2.1_amd64.deb [9044 B]
Fetched 9044 B in 0s (0 B/s)
Get:1 libxcb-sync1_1.11.1-1ubuntu1_amd64.deb [8324 B]
Fetched 8324 B in 0s (0 B/s)
Get:1 libxext6_1.3.3-1_amd64.deb [29.4 kB]
Fetched 29.4 kB in 0s (0 B/s)
Get:1 libdrm-common_2.4.91-2~16.04.1_all.deb [4764 B]
Fetched 4764 B in 0s (0 B/s)
Pulling archives
Segmentation fault
Failed to run ‘override-pull’: Exit code was 139.
Debug mode enabled, dropping into a shell
snapcraft results in this (end of the output):
Fetched 1477 kB in 0s (0 B/s)
Pulling archives
Pulling env
Building archives
Building env
Staging archives
Staging env
Priming archives
Files from the build host were migrated into the snap to satisfy dependencies that would otherwise not be met. This feature will be removed in a future release. If these libraries are needed in the final snap, ensure that the following are either satisfied by a stage-packages entry or through a part:
usr/lib/x86_64-linux-gnu/libGLU.so.1
The GLIBC version of the targeted core is 2.23. A newer libc will be required for the following files:
It’s not creating the right PATH, but can be run like this:
chris@desktop:~$ /snap/bin/pingus
Segmentation fault
chris@desktop:~$
Which as you can see causes a segmentation fault.
That is almost certain to be due to an incompatible glibc version in your build environment than that shipped with your targetted base (likely core or core18). You might have best luck installing multipass (available as a snap or on macOS) and explicitly setting base: core or base: core18 to trigger snapcraft into using it by default.
@lucyllewy > You might have best luck installing multipass
‘Software’ says “Multipass allows you to to quickly launch Ubuntu virtual machines.” - so a virtual machine as an alternative to using LXD? I followed the instructions on multipass-gui/README.md at master · robert-ancell/multipass-gui · GitHub, it worked except for $ git clone git@github.com:robert-ancell/multipass-gui, but the GUI starts. It fails with
launch failed: CPU does not support KVM extensions.
“lscpu” Flags: The list does not include kvm. Well that’s out then, I’m not buying a new CPU 
So the options are:
Interesting. I thought multipass would run fine without kvm, albeit slowly. LXD isn’t so much deprecated. But the code path you go down with snapcraft cleanbuild is ‘legacy’.
Ok, so you have another option here - --destructive-mode which will build on the machine snapcraft is executed on. This requires a base stanza in the yaml, such as base: core16 (for building on Ubuntu 16.04) or base: core18 (if you’re on an 18.04 machine). Other releases aren’t supported because of the libc (and other) issue you’ve previously seen.
So add either of those lines to the yaml, when run on a machine which is 16.04 or 18.04 and then run:-
snapcraft --destructive-mode
Let’s see how that goes?
I was wondering about that. I realised that I had seen both “snapcraft” and “snapcraft build” in examples, and was using both, so I went back to check what the difference was, but I can’t find the examples or any documentation to explain the difference. I’ll stick to snapcraft then. However it doesn’t accept the “–destructive” parameter.
name: pingus
version: '0.1'
summary: Free Lemmings(TM) clone
description: |
Pingus is a free clone of the popular Lemmings game.
|
Your goal is to guide a horde of penguins through a world full of obstacles
and penguin traps to safety. Although penguins (unlike lemmings) are rather
smart, they sometimes lack the necessary overview and now rely on you to
save them.
grade: devel
confinement: devmode
base: core18
parts:
archives:
plugin: nil
stage-packages:
# - libc6 #Not in article
- pingus
deb:
plugin: dump
source: pingus_0.7.6-4build2_amd64.deb
env:
plugin: dump
organize:
pingus.wrapper: usr/bin/pingus
apps:
pingus:
command: pingus
The build works, and it installs, but I get a segmentation fault running it.
Anything in dmesg? I imagine this binary was built against a super old version of Ubuntu and the libc is incompatible. Is there no source code available?
Nothing that means anytbing to me. I think I might be best abandoning the example which was dated 7/12/2016 and going back to my app. It’s no easier to use an example if it doesn’t work!
Hi, thanks for the concern. this is being tracked on LP: #1817300.
And here are some more words describing this PSA: classic confinement and core snapcraft issue
This has been deleted.
I’m using base: core18 and snapcraft as you suggested. As I mentioned above, I have abandoned the dodgy example and moved on to trying myapp.
I think I’ve sorted a problem with references to directories, by using a wrapper to find the executable and referring to $SNAP inside the program to find everything else. As a test, if I run it by using the file and directory reference /snap/<myapp>/current/usr/bin/<myapp> it starts without problems. (It fails when it looks for the GUI, but I would expect that as it isn’t running as a Snap so $SNAP has no value).
When I run it by typing <myapp>, or by /snap/<myapp>/x1/command-<myapp>.wrapper I get:
*** stack smashing detected ***: terminated Aborted
It therefore looks to me to be a problem with the wrapper.
...
base: core18
parts:
archives:
plugin: nil
stage-packages:
- libc6
- python-pil
deb:
plugin: dump
source: <myapp>_0.0.1_all.deb
env:
plugin: dump
organize:
<myapp>.wrapper: usr/bin/<myapp>
apps:
<myapp>:
command: <myapp>
#!/bin/sh
#export PATH="$SNAP/usr/sbin:$SNAP/usr/bin:$SNAP/sbin:$SNAP/bin:$PATH"
#export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:$SNAP/lib:$SNAP/usr/lib:$SNAP/lib/x86_64-linux-gnu:$SNAP/usr/lib/x86_64-linux-gnu"
#export LD_LIBRARY_PATH=$SNAP_LIBRARY_PATH:$LD_LIBRARY_PATH
exec "<myapp>" "$@"
This does the same:
...
base: core18
parts:
archives:
plugin: nil
stage-packages:
- libc6
- python-pil
deb:
plugin: dump
source: <myapp>_0.0.1_all.deb
apps:
<myapp>:
command: <myapp>
#!/bin/sh
export PATH="$SNAP/usr/sbin:$SNAP/usr/bin:$SNAP/sbin:$SNAP/bin:$PATH"
export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:$SNAP/lib:$SNAP/usr/lib:$SNAP/lib/x86_64-linux-gnu:$SNAP/usr/lib/x86_64-linux-gnu"
export LD_LIBRARY_PATH=$SNAP_LIBRARY_PATH:$LD_LIBRARY_PATH
exec "<myapp>" "$@"
The application installs and runs perfectly from a .deb. I have seen other threads about segmentation faults with Snaps and conclude there is a problem with Snapcraft that needs looking at. I’ve since tried this with a “Hello World!” Python3 application - it doesn’t even work with that.