Segfault when using greetd + Sway

[itaranto]

I'm using greetd as login manager with the GTK greeter and Sway.
This setup is more or less explained here and here.

After a specific upgrade, the greeter now takes a few seconds to start due to xdpw crashing and being restarted several times.

Here's the log with -l DEBUG: xdpw.log

This is what coredumpctl info says:

[I] ~ $ coredumpctl info
           PID: 3072 (xdg-desktop-por)
           UID: 976 (greeter)
           GID: 976 (greeter)
        Signal: 11 (SEGV)
     Timestamp: Sun 2021-06-13 22:02:18 -03 (14min ago)
  Command Line: /usr/lib/xdg-desktop-portal-wlr -l DEBUG
    Executable: /usr/lib/xdg-desktop-portal-wlr
 Control Group: /user.slice/user-976.slice/user@976.service/app.slice/xdg-desktop-portal-wlr.service
          Unit: user@976.service
     User Unit: xdg-desktop-portal-wlr.service
         Slice: user-976.slice
     Owner UID: 976 (greeter)
       Boot ID: a52b1ef6df664d259ee863b9aa403656
    Machine ID: 3d14cd859eed44e78935812dd176271f
      Hostname: ryzen
       Storage: /var/lib/systemd/coredump/core.xdg-desktop-por.976.a52b1ef6df664d259ee863b9aa403656.3072.1623632538000000.zst (inaccessible)
       Message: Process 3072 (xdg-desktop-por) of user 976 dumped core.

                Stack trace of thread 3072:
                #0  0x00007fe571794515 __strlen_avx2 (libc.so.6 + 0x160515)
                #1  0x000055b5f806a5c2 n/a (xdg-desktop-portal-wlr + 0x45c2)
                #2  0x00007fe57165bb25 __libc_start_main (libc.so.6 + 0x27b25)
                #3  0x000055b5f806b05e n/a (xdg-desktop-portal-wlr + 0x505e)

[emersion]

Which version if xdpw is this?

[danshick]

Looks like the first time it connects to Wayland successfully but output manager protocol versions aren't available.

22:02:16 [ERROR] - Compositor doesn't support zxdg_output_manager_v1!

All subsequent launches fail to connect to wayland.

Could you also share your relevant greetd configs? Specifically what compositor you have it launching and its configs? I'm guessing you are using greetd with cage?

[itaranto]

Which version if xdpw is this?

0.4.0-2 according to pacman

Looks like the first time it connects to Wayland successfully but output manager protocol versions aren't available.

22:02:16 [ERROR] - Compositor doesn't support zxdg_output_manager_v1!

All subsequent launches fail to connect to wayland.

Could you also share your relevant greetd configs? Specifically what compositor you have it launching and its configs? I'm guessing you are using greetd with cage?

No, I'm using greetd-gtkgreet with Sway itself, here's my greetd config:
https://gitlab.com/itaranto/dotfiles/-/tree/master/sys/etc/greetd

And this is how I launch the "real" Sway session from greetd:
https://gitlab.com/itaranto/dotfiles/-/blob/master/sys/usr/local/bin/start-sway

[danshick]

Can you post the contents of any files in /etc/sway/config.d/*? I'm looking for some form of environment variable syncing with systemd or dbus. My guess is WAYLAND_DISPLAY not being properly set in your greetd seay session.

[itaranto]

Can you post the contents of any files in /etc/sway/config.d/*? I'm looking for some form of environment variable syncing with systemd or dbus. My guess is WAYLAND_DISPLAY not being properly set in your greetd seay session.

There's only this file: /etc/sway/config.d/50-systemd-user.conf, provided by the Arch Linux's package:

# sway does not set DISPLAY/WAYLAND_DISPLAY in the systemd user environment
# See FS#63021
# Adapted from xorg's 50-systemd-user.sh, which achieves a similar goal.

exec systemctl --user import-environment DISPLAY WAYLAND_DISPLAY SWAYSOCK
exec hash dbus-update-activation-environment 2>/dev/null && \
     dbus-update-activation-environment --systemd DISPLAY WAYLAND_DISPLAY SWAYSOCK

I'm including /etc/sway/config.d/* both in my greetd Sway config as well as my user Sway config.

In case I didn't mention it before, both Sway sessions work just fine, it's just that greetd takes around 30 seconds to start due to xdpw crashing.

[danshick]

There's only this file: /etc/sway/config.d/50-systemd-user.conf, provided by the Arch Linux's package

I was hoping this wasn't there. My guess was that xdpw couldn't connect to wayland because it couldn't see the WAYLAND_DISPLAY environment variable. This included config helps to ensure that sway propagates its environment to d-bus/systemd.

In case I didn't mention it before, both Sway sessions work just fine, it's just that greetd takes around 30 seconds to start due to xdpw crashing.

Yep, makes sense. Does xdpw crash in your full sway instance as well?

[danshick]

How are you getting a debug log from xdpw inside the sway session that gtkgreet lives in, btw? I don't see any provision for that in your config.

Edit: nevermind, journalctl.

[danshick]

Try this for me and let me know what happens...

https://gitlab.com/itaranto/dotfiles/-/blob/master/sys/etc/greetd/config.toml#L5

Just as a test, change that line to:

command = "XDG_CURRENT_DESKTOP=sway sway --config /etc/greetd/sway-config"

I think your logs might indicate an issue with your full sway session and not your greetd session, but I could be wildly off base. If I'm right, you have two problems, both easily solved.

[itaranto]

Yep, makes sense. Does xdpw crash in your full sway instance as well?

Nope, it works fine. I can do video-conferencing in Sway without any issue.

How are you getting a debug log from xdpw inside the sway session that gtkgreet lives in, btw? I don't see any provision for that in your config.

Edit: nevermind, journalctl.

Yes, journalctl. I created a replacement systemd file under /etc/systemd/user/xdg-desktop-portal-wlr.service with the -l DEBUG flag to get the debug logs.

[itaranto]

Try this for me and let me know what happens...

It didn't work as it is because greetd complained about XDG_CURRENT_DESKTOP=sway not being a command.

So, what I did was to create a script /usr/local/bin/greetd-sway containing:

#!/bin/sh

export XDG_SESSION_TYPE=wayland
export XDG_SESSION_DESKTOP=sway
export XDG_CURRENT_DESKTOP=sway
sway --config /etc/greetd/sway-config

And to reference it in /etc/greetd/config.toml:

[terminal]
vt = 1

[default_session]
command = "greetd-sway"
user = "greeter"

But xdpw kept crashing.

[danshick]

Ugh, that shoots that theory. Any change in the logs?

[itaranto]

Ugh, that shoots that theory. Any change in the logs?

It's strange, xdpw is still crashing but now there's no logs.

Another strange thing is that I found a crash for gtkgreet that I can reproduce 100% of the time. Every time I enter an incorrect password it segfaults, with a correct one it doesn't. I'll report that to greetd-gtkgreet.
I think this is probably unrelated to xdwp.

[danshick]

If you build xdg-desktop-portal-wlr-git from AUR, it'll include debugging symbols and you can send us a backtrace if you're getting a segfault style crash in xdpw.

[itaranto]

If you build xdg-desktop-portal-wlr-git from AUR, it'll include debugging symbols and you can send us a backtrace if you're getting a segfault style crash in xdpw.

#0  0x00007feca2906515 in __strlen_avx2 () from /usr/lib/libc.so.6
#1  0x0000561452cf95ca in get_config_path () at ../xdg-desktop-portal-wlr-git/src/core/config.c:109
#2  init_config (config=0x7ffe4fc04eb0, configfile=<synthetic pointer>) at ../xdg-desktop-portal-wlr-git/src/core/config.c:165
#3  main (argc=1, argv=<optimized out>) at ../xdg-desktop-portal-wlr-git/src/core/main.c:84

I took a look at the code and it seems you are calling strlen over a NULL pointer, here:

	const char *home = getenv("HOME");
	size_t size_fallback = 1 + strlen(home) + strlen("/.config");

The environment variable HOME is not defined because greetd and greetd-gtkgreet run as the greeter user.
The greeter user has no home:

[I] ~ $ cat /etc/passwd|grep greeter
greeter:x:976:976:greetd greeter user:/:/bin/bash

Now that I think of, isn't HOME guaranteed to be always defined?

Let me know if you need anything else.

[itaranto]

OK, as an example, I checked the environment variables xdg-deskop-portal under the greeter user session and it doesn't contain the HOME variable.

I used strings /proc/<PID>/environment to check this.

[danshick]

You nailed it! This is a regression. @columbarius, can we make these getenv calls safe? If you don't have time, I may be able to push a PR tomorrow evening.

[columbarius]

You nailed it! This is a regression. @columbarius, can we make these getenv calls safe? If you don't have time, I may be able to push a PR tomorrow evening.

getenv calls are "safe" by default in that they either return a string or NULL, we just need to check for that.

[columbarius]

@itaranto
Thanks for finding hat. Never came to my mind, that xdpw could run as a system user without home.

Could you test if #151 fixes it, please?

[columbarius]

Looks like this got closed automatically by merging #151.
Reopening it for confirmation.

[itaranto]

@itaranto
Thanks for finding hat. Never came to my mind, that xdpw could run as a system user without home.

That's strange, I'll probably do more research, for example xdg-desktop-portal has HOME defined in my regular session but not in the greetd session.

Could you test if #151 fixes it, please?

Yes, I just built xdg-desktop-portal-wlr-git and it didn't crashed in the greetd's login screen.