@lucyllewy @sergiusens
I found something that could point to the issue…
I patched python3 as in the snapcraft snap (fixing the needed dirs)
but I still get this error in strace.
I guess the issue is that it’s looking for the girepository from the host system. Could this be an incompatibility?
If so, how can I fix it?
9638 open("/snap/ubuntu-make/x13/usr/lib/python3/dist-packages/gi/pycache/_error.cpython-35.pyc", O_RDONLY|O_CLOEXEC) = 4
9638 open("/snap/ubuntu-make/x13/usr/lib/python3/dist-packages/gi/repository/pycache/init.cpython-35.pyc", O_RDONLY|O_CLOEXEC) = 4
9638 open("/snap/ubuntu-make/x13/usr/lib/python3/dist-packages/gi/pycache/importer.cpython-35.pyc", O_RDONLY|O_CLOEXEC) = 4
9638 open("/snap/ubuntu-make/x13/usr/lib/python3/dist-packages/gi/pycache/module.cpython-35.pyc", O_RDONLY|O_CLOEXEC) = 4
9638 open("/snap/ubuntu-make/x13/usr/lib/python3/dist-packages/gi/pycache/types.cpython-35.pyc", O_RDONLY|O_CLOEXEC) = 4
9638 open("/snap/ubuntu-make/x13/usr/lib/python3/dist-packages/gi/pycache/_constants.cpython-35.pyc", O_RDONLY|O_CLOEXEC) = 4
9638 open("/snap/ubuntu-make/x13/usr/lib/python3/dist-packages/gi/pycache/docstring.cpython-35.pyc", O_RDONLY|O_CLOEXEC) = 4
9638 open("/snap/ubuntu-make/x13/usr/lib/python3/dist-packages/gi/pycache/_propertyhelper.cpython-35.pyc", O_RDONLY|O_CLOEXEC) = 4
9638 open("/snap/ubuntu-make/x13/usr/lib/python3/dist-packages/gi/pycache/_signalhelper.cpython-35.pyc", O_RDONLY|O_CLOEXEC) = 4
9638 open("/snap/ubuntu-make/x13/usr/lib/python3/dist-packages/gi/overrides/pycache/init.cpython-35.pyc", O_RDONLY|O_CLOEXEC) = 4
9638 open("/snap/ubuntu-make/x13/usr/lib/python3/dist-packages/gi/repository", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 4
9638 open("/usr/lib/x86_64-linux-gnu/girepository-1.0", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 4
9638 open("/usr/lib/x86_64-linux-gnu/girepository-1.0/GLib-2.0.typelib", O_RDONLY) = 5
9638 open("/usr/lib/girepository-1.0", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 4
9638 open("/usr/lib/x86_64-linux-gnu/girepository-1.0", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 4
9638 open("/usr/lib/x86_64-linux-gnu/girepository-1.0/GLib-2.0.typelib", O_RDONLY) = 5
9638 open("/usr/lib/girepository-1.0", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 4
That’s not the issue…
at the moment the only thing I can check are the last lines of the strace:
24746 open("/snap/ubuntu-make/x3/usr/lib/python3/dist-packages/pycache/gnupg.cpython-35.pyc", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
24746 open("/snap/ubuntu-make/x3/usr/lib/python3/dist-packages/gnupg.py", O_RDONLY|O_CLOEXEC) = 33
24746 open("/snap/ubuntu-make/x3/lib/python3.5/site-packages/umake/frameworks/pycache/web.cpython-35.pyc", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
24746 open("/snap/ubuntu-make/x3/lib/python3.5/site-packages/umake/frameworks/web.py", O_RDONLY|O_CLOEXEC) = 33
24746 open("/home/galileo/.local/share/umake/go/go-lang", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = -1 ENOENT (No such file or directory)
24766 open("/snap/ubuntu-make/x3/usr/lib/python3.5/pycache/netrc.cpython-35.pyc", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
24766 open("/snap/ubuntu-make/x3/usr/lib/python3.5/netrc.py", O_RDONLY|O_CLOEXEC) = 33
24766 open("/snap/ubuntu-make/x3/usr/lib/python3.5/pycache/shlex.cpython-35.pyc", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
24766 open("/snap/ubuntu-make/x3/usr/lib/python3.5/shlex.py", O_RDONLY|O_CLOEXEC) = 33
24766 open("/snap/ubuntu-make/x3/usr/lib/python3.5/encodings/pycache/idna.cpython-35.pyc", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
24766 open("/snap/ubuntu-make/x3/usr/lib/python3.5/encodings/idna.py", O_RDONLY|O_CLOEXEC) = 33
24766 open("/snap/ubuntu-make/x3/usr/lib/python3.5/pycache/stringprep.cpython-35.pyc", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
24766 open("/snap/ubuntu-make/x3/usr/lib/python3.5/stringprep.py", O_RDONLY|O_CLOEXEC) = 33
24766 open("/etc/host.conf", O_RDONLY|O_CLOEXEC) = 33
24766 open("/etc/resolv.conf", O_RDONLY|O_CLOEXEC) = 33
24766 — SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0xb0} —
24756 +++ killed by SIGSEGV (core dumped) +++
24766 +++ killed by SIGSEGV (core dumped) +++
24746 +++ killed by SIGSEGV (core dumped) +++
I took a look at your snap layout and found a couple of interesting things.
For the type of application you are working on, in https://github.com/ubuntu/ubuntu-make/blob/master/snap/umake-wrapper,
- the use of
LD_LIBRARY_PATH will cause segfaults when shelling out.
- if using the python plugin,
PYTHONHOME and PYTHONUSERBASE need not be set, for the same reason, if anything you shell out to happens to be a python application (like the case of bzr), you will run into problems (segfaults and missing python package issues).
-
$SNAP/usr/bin holds more that the python runtime, exporting that will certainly cause segfaults. If anything in code you own needs to re-exec itself, it would be best handled in the code.
Thanks!
I removed the LD_LIBRARY_PATH in a branch (https://github.com/ubuntu/ubuntu-make/tree/patch_snap)
Since I’m using python3-gi, do I need to set GI_TYPELIB_PATH?
I noticed that the snap is looking for those only in the host system without…
I am sorry to say that I do not know about the internals (or externals) of python-gi.
But do you know if the girepository package is something I should include in the snap?
Is there a reason for the system to not look for it in the snap in the first place?
If you can explain to me how girepository and/or python-gi work I could lend a helping hand.
The reason for it to not look into the snap in the first place is implementation specific to the libraries used. Maybe someone more familiar with the glib/gtk stack can help.
As far as I can tell libgirepository manages the actual bindings from other languages to gtk…
I don’t know more…
The only reason to look at the system ones is in case there’s no change in the bindings for newer versions of gtk I guess…
@didrocks might know more
So the problems might be two.
The first is the one you pointed out…
(we reexec to set the euid to set root…how is root set in snapcraft?)
The other issue seems to be with the requests library…
The segfault happens just after a requests log (without a reexec in this case):
“INFO: Starting new HTTPS connection (1): golang.org”
@sergiusens
I updated the branch with the changes…
Now the re-exec is handled in the code…
The issue that remains now is with the requests module I think
libgirepository is needed as we are using glib for gsettings and other GNOME technology to integrate with the platform.
I added a condition in the re-exec:
if os.getenv(“SNAP”):
logger.debug(“Found snap environment. Running correct python version”)
cmd.extend(["{}/usr/bin/python3".format(os.getenv(“SNAP”))])
This takes care of the re-exec, calling the necessary python binary
Now the issue seems to still be with the requests module
I tried to enable the debug logging for the requests and http modules with this:
import http.client as http_client
http_client.HTTPConnection.debuglevel = 1
requests_log = logging.getLogger(“requests.packages.urllib3”)
requests_log.setLevel(logging.DEBUG)
requests_log.propagate = True
Outside the snap I get:
DEBUG: Starting new HTTPS connection (1): golang.org
send: b’GET /dl/ HTTP/1.1\r\nHost: golang.org\r\nUser-Agent: python-requests/2.18.4\r\nAccept-Encoding: gzip, deflate\r\nAccept: /\r\nConnection: keep-alive\r\n\r\n’
reply: ‘HTTP/1.1 200 OK\r\n’
In the snap:
INFO: Starting new HTTPS connection (1): golang.org
Segmentation fault (core dumped)
Can you share the actual snap?
The yaml is in the github repo: https://github.com/ubuntu/ubuntu-make/blob/patch_snap/snap/snapcraft.yaml
The only change I made now is the patches. I can remove the python patch since strace shows that the correct paths are used
Can you not release the snap you built onto a channel branch? snapcraft push <snap-file> --release edge/ld-path or another name different than ld-path?
@didrocks is the owner of the snap channel
and it’s automated, from the master branch.
I can link to the .snap I built locally if you can test it…
EDIT: not locally…via cleanbuild
This is the snap: https://www.dropbox.com/s/kgl94eu50emnt3y/ubuntu-make_master_amd64.snap?dl=0
Apparently I can still push manually…
pushing now!
And done.
Revision 275 is the manually uploaded one
@sergiusens
Did you manage to look at the snap now that it’s in the edge channel?
Hi! Just writing here since I’m not sure this needs a full new thread…
The new snap pushed to the edge channel works, but it’s built on core18
When will it be possible to build on core18 in build.snapcraft.io?
