Crash in sddm-greeter

Ask Fedora
, , ,
1

[ 25.295862] sddm-greeter[1633]: segfault at 10 ip 00007f30f7428bc4 sp 00007ffc547baac8 error 4 in libQt5VirtualKeyboard.so.5.15.6[7f30f7421000+27000]

How can I diagnose this crash in sddm-greeter?
Better yet, does anyone know the solution.
I don’t know basics, such as how to enable crash dumps for running that (part of the system startup). I do know how to get the backtrace from a crashdump and find and sometimes understand the relevant source code.

I’m pretty sure this is a race condition. My GUESS is that sddm starts X, then starts sddm-greeter which tries something before X is ready.

I have a very old nvidia card (always has failed entirely with nouveau or with wayland, but has been working with the nvidia 340 driver and X11).

What triggered this is that I cloned my fedora 35 from an old hard drive to an ssd (which I now think changed the timing of sddm’s child processes causing this failure). But I initially misunderstood the black screen symptom, thinking I’d cloned wrong. So I tried upgrading the kernel of the clone, in case that overwrote whatever was cloned wrong. So I have:

On ssd:
6.0.7-200.fc36.x86_64 which always fails.
6.0.7-100.fc35.x86_64 which rarely, but sometime, works

On hard drive:
5.15.15-200.fc35.x86_64 which almost never (under 1 in 100) has this problem in long time use
6.0.7-100.fc35.x86_64 which worked 2 of the 3 times I tried it.

2

I think I have a work around, which I think supports my guess that sddm-greeter was starting before X is ready.

I think this is just “work around” rather than solution because I think sddm-greeter (or the helper that launches it) should be able to detect that X is not ready yet and wait a bit, and if X still isn’t ready should fail both more gracefully and more informatively.

I put an xrandr command into /etc/sddm/Xsetup

If my guesses about this are correct, xrandr does know how to wait a bit if it starts before X, and the helper that launches sddm-greeter waits for Xsetup, so now sddm-greeter doesn’t start too soon.

That xrandr command is something I wanted there anyway (my displays are portrait mode, so my login screen has always been sideways).
When I previously tried to discover how to do that, I didn’t know how to construct the right xrandr command and the Xsetup I was using wasn’t executed anyway and a sideways login screen wasn’t worth that much effort to fix.

But while researching this problem, I came across:

  1. the correct Xsetup is in /etc/sddm
    The instructions I previously found and followed said it was in /usr/share/sddm/scripts
    Maybe some configuration process copies from /usr/share/sddm/scripts (I don’t know). But that wasn’t happening so my edits to /usr/share/sddm/scripts/Xsetup accomplished nothing
  2. arandr can easily give my the xrandr command to match the display arrangement I configured with the easier GUI tools.

I still only have Fedora 35 working.
This work around makes Fedora 36 get further before failing, but then fail worse (can’t even ctrl-alt-F3 to get to a command prompt to try to diagnose).

3

It sounds similar to this bug report: 2057419 – SDDM crashes shortly after login

In the above-linked report, someone stated:

I switched from sddm on Wayland to sddm on X with sudo dnf swap sddm-wayland-plasma sddm-x11 as described at Changes/WaylandByDefaultForSDDM - Fedora Project Wiki I logged out of Plasma on Wayland to sddm on X normally, and the sddm-greeter crash wasn’t shown in the journal.

Does switching back to sddm-x11 by running sudo dnf swap sddm-wayland-plasma sddm-x11 fix the problem?

1 Like
4

That does not sound to me like a similar bug report to the primary issue I described and for which I found a work around.

I don’t understand the dnf command you are suggesting, but the idea of switching either to of from wayland does not fit my situation.

As I indicated above, I use x11 because wayland is not compatible with the only driver that works for the obsolete nvidia card I’m using. That closed source driver is missing features needed by wayland, and I can’t use nouveau because it doesn’t correctly support this card.

I can’t understand enough of that thread you linked, combined with how little I know about my remaining Fedora failure, so I can’t be sure it isn’t the same bug. I know for sure that is not the bug I had in both 35 and 36 and worked around in both. Maybe it is the one I still have in 36 (not in 35) after that work around.

But, as I said, I’m using x11 and that bug description seems to be in wayland. Even if wayland isn’t inherent in that bug, it does affect all the information posted there. So probably not the same bug (because that bug is likely wayland specific) and even if it might be the same bug, I don’t know how to translate any of what I see there into a form that applies to my situation.

5

I may have misunderstood the problem. My reading of the bug report was that SDDM may try to run on either X or wayland independently of the window manager (GNOME/Plasma/whatever). If you have a system that doesn’t support wayland and you want to make sure that SDDM is using X, then you may need to specify that you want that by running sudo dnf swap sddm-wayland-plasma sddm-x11. I don’t think SDDM would try to start before X if sddm-x11 is installed. But I am also just guessing. It looks like there have been some significant changes and problems in recent versions of SDDM. So trying to upgrade or downgrade the various related packages might prove fruitful. That’s the best suggestion I can offer. :slightly_smiling_face:

Edit: You could also try using a different desktop greeter; even if only temporarily until whatever the problem is gets resolved. To switch them, you would probably need to sign in on one of the virtual terminals (Ctrl+Alt+F3, Ctrl+Alt+F4, etc.). From there I think you should be able to stop and disable sddm (systemctl stop sddm.service && systemctl disable sddm.service) and then start and enable another desktop manager (systemctl enable gdm.service && systemctl start gdm.service).

6

While I was still booting F35 from a slower hard drive (and had the problem that was the main topic of this thread so rarely, that I didn’t try to diagnose it) I found that sddm sometimes randomly switched the default to wayland, causing a crash if I logged in without noticing that. So I googled and found and used some method to disable wayland, so sddm never offers it. It wasn’t the method you suggested, but likely the same effect.

sddm starts before X in the normal workstation boot sequence. Then sddm runs a helper process that both starts X and starts sddm_greeter.
All the behavior has made me very confident in my guess that sddm_greeter was starting before X was ready for whatever sddm_greeter told it to do. That could be considered a bug in the helper program that sddm uses to start both X and the greeter (if you consider the greeter to be an ordinary program depending on X, rather than a special program expected to often be the first user of a new instance of X). The helper could certainly be changed to solve this bug. But I think the overall design would be cleaner and more robust if this were treated as an sddm_greeter bug and fixed there.

I have too many other things to do, so I won’t dig further into the source code to propose a specific correction. The workaround of fixing it in the Xsetup script is much easier.

I’m confident the remaining problem, that stops me from using F36, is unrelated. I discovered I have a coredump file for that, which I will try to get a backtrace from shortly. If I learn anything, I think I should start a new thread for that issue. I might try your suggestion of trying gdm for that.

7

:bluethumb:

As you use KDE I would propose to give lightdm a try. If you install GDM you really fast need Gnome-shell dependent components and you will get a mess with the kde specific config.
For example the lock-screen you would need install independent.

1 Like
8

As it turns out, I don’t have a coredump for the F36 problem.
I have lots of coredumps for xdg-desktop-por (don’t yet know what that is). But I get those in both F35 and F36 and I don’t know of any symptom related to those failures.

9

There is another bug report for sddm that mentions xdg-desktop-portal (currently the second item in the list shown at the below link).

https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=CLOSED&columnlist=product%2Ccomponent%2Cassigned_to%2Cbug_status%2Cshort_desc%2Cchangeddate%2Cbug_severity&component=sddm&order=status%2C%20assigned_to%2C%20id%2C%20&product=Fedora&query_format=advanced

Edit: Well, I thought that link would keep the sorting. But it looks like it didn’t. Just click twice on the “Changed” column to get the bugs sorted by date with the newest ones at the top.

10

More and more issues in this topic, I’d test fresh F37 (Plasma 5.26.3) at least to check whether I’m not dealing with something already fixed in newer releases.

You could also try sddm running on weston ( sddm-wayland-generic) instead of kwin ( sddm-wayland-plasma): sudo dnf swap sddm-x11 sddm-wayland-generic Nevermind, Nvidia 340 with wayland will be a problem anyway. And with newer kernels too. Stick with sddm-x11. Almost any ATI/AMD GPU will be better.

11

I opened two new threads for the two issues here that are not actually related to this thread’s topic of sddm-greeter

https://discussion.fedoraproject.org/t/f36-nvidia-340xx-crash/67411?u=john2fx

https://discussion.fedoraproject.org/t/coredump-from-xdg-desktop-portal-kde/75831?u=john2fx

Sorry I triggered all this off topic discussion by mentioning the two other issues here (before I understood how separate they are from the sddm-greeter issue). But I think the discussion will be too hard to follow if the three topics stayed mixed in this thread.

Probably, I’ll look at black friday sales and finally buy a decent graphics card. My computer case, graphics card, and one hard drive are all ancient, while most components (SSD, motherboard, cpu, ram, power supply, displays, etc. are pretty new).

While the sddm-greeter bug probably needed the combination of slow graphics card with fast SSD root partition to make it happen, it is still a bug and still ought to be fixed.

12

You can get a used AMD GCN card with vulkan support for cheap. Just double check before buying, they mix different architectures a lot List of AMD graphics processing units - Wikipedia

13

Any of the nvidia GPUs 1030 and up are fully supported by the latest nvidia drivers. Some older ones as well, but I do not know the cutoff. The latest nvidia drivers also support wayland.

14

My work around is apparently not 100%, so my understanding of what xrandr was accomplishing must be incorrect.

Today it failed once (worked 2 out of 2 times since, so likely a random occurrence, rather than a change). (I verified it is the same failure I started this thread for, not some other random occurrence).

I’ve trying to understand some other things, that don’t behave the way documentation says they should, so I’ve rebooted a LOT in the last few days. This is the only one of those reboots, since I did that workaround, that failed (where before the work around only a small fraction didn’t fail). So I’m still sure the failure is loosing some race condition. But what waits for what (in order to prevent a race condition) apparently doesn’t work the way I assumed.

Meanwhile, I’m shopping for a good sale on something like a Radeon 6600xt.

My Windows computer has a Radeon 5500xt, which has generally worked well. I tried long ago to test linux on that hardware with a live Fedora on a slow usb stick. I had problems with everything including the display adapter. It has 4 displays connected, which was tricky to get working in Windows and I never got close in Linux with a live usb stick.
I’m working on creating an ordinary Fedora 37 install (not live, so it is easier to tweak things and keep them when rebooting) on a larger/faster USB device to rerun that test (and for other purposes). If I can’t get that system to work right, that would change my plans to put a 6600xt and a third display on this system.

Edit: With a few minor glitches to work out, my F37 system seems to work with four 2560x1440 displays on my 5500.

15

I bought and switched to the following display card:

0a:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Navi 23 [Radeon RX 6650 XT] (rev c1) (prog-if 00 [VGA controller])
        Subsystem: Micro-Star International Co., Ltd. [MSI] Device 5027
        Flags: bus master, fast devsel, latency 0, IRQ 68, IOMMU group 16
        Memory at 7c00000000 (64-bit, prefetchable) [size=8G]
        Memory at 7e00000000 (64-bit, prefetchable) [size=256M]
        I/O ports at e000 [size=256]
        Memory at fcb00000 (32-bit, non-prefetchable) [size=1M]
        Expansion ROM at fcc00000 [disabled] [size=128K]
        Capabilities: [48] Vendor Specific Information: Len=08 <?>
        Capabilities: [50] Power Management version 3
        Capabilities: [64] Express Legacy Endpoint, MSI 00
        Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+
        Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010 <?>
        Capabilities: [150] Advanced Error Reporting
        Capabilities: [200] Physical Resizable BAR
        Capabilities: [240] Power Budgeting <?>
        Capabilities: [270] Secondary PCI Express
        Capabilities: [2a0] Access Control Services
        Capabilities: [2d0] Process Address Space ID (PASID)
        Capabilities: [320] Latency Tolerance Reporting
        Capabilities: [410] Physical Layer 16.0 GT/s <?>
        Capabilities: [440] Lane Margining at the Receiver <?>
        Kernel driver in use: amdgpu
        Kernel modules: amdgpu

I also switched to using Wayland (which never worked with my old display card and driver). I added a very cheap ($148 and low quality) 4K 50 inch TV as a third monitor. The old card couldn’t drive that together with my two portrait mode 1620x2880 32 inch monitors.

The new setup did not ever show the sddm-greeter crash even when I had removed the Xsetup script because the --output names needed are different for this card/driver and I didn’t initially know what they should be.

To find out how to get the portrait mode displays right in the login screen, I had to switch back from X11 to Wayland and then use arandr to find out the output names needed for xrandr in Xsetup for the login screen. arandr does not give correct output when run in Wayland and I don’t know any other method to get that info. If someone tells me a cleaner way, that would be nice, but I’m managing without.

For Wayland, I wanted the adjacent portrait (2880) 32-inch and landscape (2160) 50 inch to pass windows level and at the same size between them. That meant setting the scale (below 100%) and pos of the 50-inch with finer control than the GUI Display Configuration -- System Settings permits, so I had to find the file that is stored in and edit it. If someone tells me a cleaner way, that would be nice, but I’m managing without.

I know my original 3240x2880 pixel (31x27.5 inch) desktop is more than most computer users would even want. But the way I handle visual information, combined with the way I use computers, made it very limiting. That was my real reason to ditch the old card. Even low quality, the extra 3840x2160 of desktop area helps me a lot.