From: Bengt Richter <bokr@bokr.com>
To: 37308@debbugs.gnu.org
Subject: bug#37308: guix weston-launch segfaults, /usr/bin/weston-launch does not -- why?
Date: Thu, 5 Sep 2019 05:17:48 -0700 [thread overview]
Message-ID: <20190905121748.GB6283@PhantoNv4ArchGx.localdomain> (raw)
I used guix strace and /usr/bin/strace to try to diagnose weston-launch,
from grepping my history:
531 /usr/bin/strace -fyk -o wes-launch-fyk $(which weston-launch|xargs readlink -f)
553 /usr/bin/strace -fyk -o wes-launch-fyk-usr $(which /usr/bin/weston-launch|xargs readlink -f)
I used /usr/bin/strace because it still had the -k option:
$ diff -u <(/usr/bin/strace -h) <(strace -h)
--- /dev/fd/63 2019-09-05 01:38:07.086388920 -0700
+++ /dev/fd/62 2019-09-05 01:38:07.086388920 -0700
@@ -7,7 +7,6 @@
Output format:
-a column alignment COLUMN for printing syscall results (default 40)
-i print instruction pointer at time of syscall
- -k obtain stack trace between each syscall
-o file send trace output to FILE instead of stderr
-q suppress messages about attaching, detaching, etc.
-r print relative timestamp
$
Could we have it back, or is it a security issue? Anyway, it does a LOT
of work, so it makes the trace very slow -- but still useful.
The first thing I noticed was a permission problem.
Note difference between trace logs (no EACCES errors for /usr/bin/weston-launch):
$ grep EACC wes-launch-fyk
3989 openat(AT_FDCWD, "/dev/input/event3", O_RDWR|O_NONBLOCK|O_CLOEXEC) = -1 EACCES (Permission denied)
3989 openat(AT_FDCWD, "/dev/input/event9", O_RDWR|O_NONBLOCK|O_CLOEXEC) = -1 EACCES (Permission denied)
3989 openat(AT_FDCWD, "/dev/input/event10", O_RDWR|O_NONBLOCK|O_CLOEXEC) = -1 EACCES (Permission denied)
3989 openat(AT_FDCWD, "/dev/input/event0", O_RDWR|O_NONBLOCK|O_CLOEXEC) = -1 EACCES (Permission denied)
3989 openat(AT_FDCWD, "/dev/input/event2", O_RDWR|O_NONBLOCK|O_CLOEXEC) = -1 EACCES (Permission denied)
3989 openat(AT_FDCWD, "/dev/input/event1", O_RDWR|O_NONBLOCK|O_CLOEXEC) = -1 EACCES (Permission denied)
3989 openat(AT_FDCWD, "/dev/input/event7", O_RDWR|O_NONBLOCK|O_CLOEXEC) = -1 EACCES (Permission denied)
3989 openat(AT_FDCWD, "/dev/input/event11", O_RDWR|O_NONBLOCK|O_CLOEXEC) = -1 EACCES (Permission denied)
3989 openat(AT_FDCWD, "/dev/input/event12", O_RDWR|O_NONBLOCK|O_CLOEXEC) = -1 EACCES (Permission denied)
3989 openat(AT_FDCWD, "/dev/input/event13", O_RDWR|O_NONBLOCK|O_CLOEXEC) = -1 EACCES (Permission denied)
3989 openat(AT_FDCWD, "/dev/input/event14", O_RDWR|O_NONBLOCK|O_CLOEXEC) = -1 EACCES (Permission denied)
3989 openat(AT_FDCWD, "/dev/input/event15", O_RDWR|O_NONBLOCK|O_CLOEXEC) = -1 EACCES (Permission denied)
3989 openat(AT_FDCWD, "/dev/input/event16", O_RDWR|O_NONBLOCK|O_CLOEXEC) = -1 EACCES (Permission denied)
3989 openat(AT_FDCWD, "/dev/input/event4", O_RDWR|O_NONBLOCK|O_CLOEXEC) = -1 EACCES (Permission denied)
3989 openat(AT_FDCWD, "/dev/input/event8", O_RDWR|O_NONBLOCK|O_CLOEXEC) = -1 EACCES (Permission denied)
3989 openat(AT_FDCWD, "/dev/input/event5", O_RDWR|O_NONBLOCK|O_CLOEXEC) = -1 EACCES (Permission denied)
3989 openat(AT_FDCWD, "/dev/input/event6", O_RDWR|O_NONBLOCK|O_CLOEXEC) = -1 EACCES (Permission denied)
3989 ioctl(4</dev/dri/card0>, DRM_IOCTL_DROP_MASTER, 0) = -1 EACCES (Permission denied)
$
$ grep EACC wes-launch-fyk-usr
$
(The above grep found no (! :) EACCES problems for /usr/bin/weston-launch in the strace ouput)
Here's my attempt to see what kind of errors happened:
$ egrep -ohe '-1 E.*' wes-launch-fyk|sort|uniq -c|sort -h
1 -1 EPERM (Operation not permitted)
2 -1 ENOTTY (Inappropriate ioctl for device)
18 -1 EACCES (Permission denied)
40 -1 EINVAL (Invalid argument)
640 -1 ENOENT (No such file or directory)
$
EINVALs look like they may mostly be legitimate probes for input devices,
and ENOENTs are mostly walking through all the places to look for config data
-- which seems like someone could memoize away once at login time so a program
would usually just have to do a single am-I-newer-than-my-memoized-config-data check.
The /usr/bin/weston-launch succeeded in bringing up the gui weston/wayland desktop
with an icon for starting a terminal, so naturally it did a lot more, and bumped
into more things. Some look like bugs, but I'm not sure using /usr/bin/strace like
/usr/bin/strace -fyk -o wes-launch-fyk $(which weston-launch|xargs readlink -f)
was not itself producing some errors. Amazing tool anyway :)
$ egrep -ohe '-1 E.*' wes-launch-fyk-usr|sort|uniq -c|sort -h
1 -1 EBADF (Bad file descriptor)
1 -1 EPERM (Operation not permitted)
3 -1 ENOTTY (Inappropriate ioctl for device)
68 -1 EAGAIN (Resource temporarily unavailable)
86 -1 EINVAL (Invalid argument)
984 -1 ENOENT (No such file or directory)
$
I included the -y option so you can see the files as </path/to/file> in the strace,
so it seems /dev/dri/card0 produced EPERM for both versions of weston-launch.
Idk what _IOC does to /dev/tty1, but I guess the <anon_inode:[eventpoll]> might come from
exiting the gui desktop using Ctl-Alt-Backspace.
BTW, I have noticed that on returning to console after such an exit, I lose write permission
to /dev/stderr -- don't know what that means, but I get it back if I log out and log back in.
$ egrep '(EBADF|EPERM|ENOTTY)' wes-launch-fyk wes-launch-fyk-usr
wes-launch-fyk:3989 ioctl(0</dev/tty1>, _IOC(_IOC_NONE, 0x4b, 0x51, 0), 0x1) = -1 ENOTTY (Inappropriate ioctl for device)
wes-launch-fyk:3990 ioctl(12</dev/dri/card0>, DRM_IOCTL_I915_GEM_CONTEXT_SETPARAM, 0x7fffc5200270) = -1 EPERM (Operation not permitted)
wes-launch-fyk:3989 ioctl(0</dev/tty1>, _IOC(_IOC_NONE, 0x4b, 0x51, 0), 0) = -1 ENOTTY (Inappropriate ioctl for device)
wes-launch-fyk-usr:5421 ioctl(0</dev/tty1>, _IOC(_IOC_NONE, 0x4b, 0x51, 0), 0x1) = -1 ENOTTY (Inappropriate ioctl for device)
wes-launch-fyk-usr:5422 ioctl(15</dev/dri/card0>, DRM_IOCTL_I915_GEM_CONTEXT_SETPARAM, 0x7ffdb7571460) = -1 EPERM (Operation not permitted)
wes-launch-fyk-usr:5422 epoll_ctl(17<anon_inode:[eventpoll]>, EPOLL_CTL_DEL, 19, NULL) = -1 EBADF (Bad file descriptor)
wes-launch-fyk-usr:5421 ioctl(0</dev/tty1>, _IOC(_IOC_NONE, 0x4b, 0x51, 0), 0) = -1 ENOTTY (Inappropriate ioctl for device)
wes-launch-fyk-usr:5421 ioctl(0</dev/tty1>, DRM_IOCTL_DROP_MASTER, 0) = -1 ENOTTY (Inappropriate ioctl for device)
$
The output logged to the console tty1 can be extracted from the strace,
along with the segfault:
egrep '/dev/tty1|SEG' wes-launch-fyk|tail -20
3990 write(2</dev/tty1>, "event5: opening input device '/d"..., 83) = 83
3990 write(2</dev/tty1>, "[00:35:11.032] ", 15) = 15
3990 write(2</dev/tty1>, "event5 - failed to create input"..., 60) = 60
3989 write(2</dev/tty1>, "Error opening device /dev/input/"..., 58) = 58
3990 write(2</dev/tty1>, "[00:35:11.100] ", 15) = 15
3990 write(2</dev/tty1>, "event6: opening input device '/d"..., 83) = 83
3990 write(2</dev/tty1>, "[00:35:11.110] ", 15) = 15
3990 write(2</dev/tty1>, "event6 - failed to create input"..., 60) = 60
3990 write(2</dev/tty1>, "[00:35:11.136] ", 15) = 15
3990 write(2</dev/tty1>, "warning: no input devices on ent"..., 191) = 191
3990 write(2</dev/tty1>, "[00:35:11.144] ", 15) = 15
3990 write(2</dev/tty1>, "failed to create input devices\n", 31) = 31
3990 close(0</dev/tty1> <unfinished ...>
3990 --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x7f2ee04e23c4} ---
3990 +++ killed by SIGSEGV (core dumped) +++
3989 wait4(-1, [{WIFSIGNALED(s) && WTERMSIG(s) == SIGSEGV && WCOREDUMP(s)}], 0, NULL) = 3990
3989 ioctl(0</dev/tty1>, _IOC(_IOC_NONE, 0x4b, 0x51, 0), 0) = -1 ENOTTY (Inappropriate ioctl for device)
3989 ioctl(0</dev/tty1>, KDSKBMODE, 0x3) = 0
3989 ioctl(0</dev/tty1>, KDSETMODE, 0) = 0
3989 ioctl(0</dev/tty1>, VT_SETMODE, 0x7ffeaa561f84) = 0
I still haven't nailed just where it happens, but I need some zs right now :)
Any help getting my guix weston-launch running would be greatly appreciated!
BTW, icecat sort of runs on top of /usr/bin/weston-launch, but it crashes seemingly on any save-as type of action,
blasting all the way back to the login console, not just back to the weston-terminal from which it was launched.
BTW2, I finally got icecat to show useful output after shotgunning like:
guix package -i nss-certs
guix upgrade icecat
guix install fontconfig
guix install libxfont
guix install font-dejavu -->> this finally gave icecat a font
guix install moka-icon-theme
guix install hicolor-icon-theme
guix install less
guix package -i libsigsegv
I think it would be nice to be advised that font-dejavu may solve
the hex-box-font problem for a novice ;-)
installed mozjs also, but must have logged it elsewhere
(it's of course in guix package -l)
Anyway, TIA
Regards,
Bengt Richter
next reply other threads:[~2019-09-05 12:19 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-05 12:17 Bengt Richter [this message]
2019-09-05 20:22 ` bug#37308: guix weston-launch segfaults, /usr/bin/weston-launch does not -- why? Tobias Geerinckx-Rice via Bug reports for GNU Guix
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190905121748.GB6283@PhantoNv4ArchGx.localdomain \
--to=bokr@bokr.com \
--cc=37308@debbugs.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).