Bug 1008677

Created attachment 700792 [details]
Backtrace for a coredump from a run of “Simple Desktop Display Manager”

Can this data display from a debugger help to avoid further unwanted segmentation faults from this program?

According to bug#1012197, this seems to be no longer relevant I suppose.

And it likely wasn't a bug in sddm anyway, more some underlying issue (broken nvidia installation), as you reported the same problem for 6! different display managers at the same time:
Bug#1008674
Bug#1008678
Bug#1008680
Bug#1008682
Bug#1008683

(In reply to Wolfgang Bauer from comment #2)
> According to bug#1012197, this seems to be no longer relevant I suppose.

I would appreciate a better explanation for a segmentation fault while I extended my views around the reported software situation a bit more in the meantime.


> And it likely wasn't a bug in sddm anyway, more some underlying issue
> (broken nvidia installation), as you reported the same problem for 6!
> different display managers at the same time:

A special software combination triggered some difficulties for the desired graphical login which worked before this hiccup for a while.

(In reply to Markus Elfring from comment #3)
> (In reply to Wolfgang Bauer from comment #2)
> > According to bug#1012197, this seems to be no longer relevant I suppose.
> 
> I would appreciate a better explanation for a segmentation fault while I
> extended my views around the reported software situation a bit more in the
> meantime.

SDDM crashes with a segfault if Xorg cannot be started.
That's a secondary problem though (the main one is that Xorg doesn't start in the first place)

The SDDM segfault should be fixed in the latest version that is on the way to Tumbleweed.
But if Xorg doesn't start, there's no way for the displaymanager to show up anyway.

> > And it likely wasn't a bug in sddm anyway, more some underlying issue
> > (broken nvidia installation), as you reported the same problem for 6!
> > different display managers at the same time:
> 
> A special software combination triggered some difficulties for the desired
> graphical login which worked before this hiccup for a while.

We do not support "special software combinations"...

(In reply to Wolfgang Bauer from comment #4)
> The SDDM segfault should be fixed in the latest version that is on the way
> to Tumbleweed.

PS, this is the fix:
https://build.opensuse.org/package/view_file/KDE:Frameworks5/sddm/0005-Cleanup-dangling-pointer-in-SocketServer-725.patch?expand=1

But I want to repeat: it won't help really, the SDDM segfault (and the fix) is just "cosmetical".
If Xorg fails to start, you won't get a graphical interface or a login greeter.

And as this bug report actually is about SDDM's segfault according to the title, we might just as well close it as fixed. ;-)

The submission to Factory/Tumbleweed has been accepted 2 hours ago, so should be in the next Tumbleweed snapshot.

Feel free to reopen or file a new bug report if SDDn still crashes with a segfault in case Xorg fails to start.

(In reply to Wolfgang Bauer from comment #4)
> SDDM crashes with a segfault if Xorg cannot be started.

I was not really aware about this software behaviour before.
Do any more bug reports exist for such a detail?


> the main one is that Xorg doesn't start in the first place

I am curious about further corresponding failure reasons.


> We do not support "special software combinations"...

I got an other impression on how automatic quality assurance could eventually improve the situation also around the evolution of components from openSUSE Tumbleweed.


(In reply to Wolfgang Bauer from comment #5)
> https://build.opensuse.org/package/view_file/KDE:Frameworks5/sddm/0005-Cleanup-dangling-pointer-in-SocketServer-725.patch?expand=1

Thanks for the link.


> But I want to repeat: it won't help really, the SDDM segfault (and the fix)

I find a bit more software development attention useful also around an issue like “Cleanup dangling pointer in SocketServer”.
https://github.com/sddm/sddm/pull/725


> is just "cosmetical".

I imagine that the added destructor can prevent further hiccups, can't it?


> If Xorg fails to start, you won't get a graphical interface
> or a login greeter.

I hope that the next error messages might become easier to handle.

(In reply to Markus Elfring from comment #7)
> (In reply to Wolfgang Bauer from comment #4)
> > SDDM crashes with a segfault if Xorg cannot be started.
> 
> I was not really aware about this software behaviour before.
> Do any more bug reports exist for such a detail?

Yes, https://github.com/sddm/sddm/pull/725 as you mentioned yourself.

And that should be fixed in the next Tumbleweed update, as I wrote.

> > the main one is that Xorg doesn't start in the first place
> 
> I am curious about further corresponding failure reasons.

As I already tried to explain to you half a year ago in the openSUSE Forums and you were also told in your bug report about xdm, this is to be expected after every major update to the kernel, Xorg or Mesa.

You need to reinstall the nvidia driver afterwards.

> > We do not support "special software combinations"...
> 
> I got an other impression on how automatic quality assurance could
> eventually improve the situation also around the evolution of components
> from openSUSE Tumbleweed.

Tumbleweed is tested, but only the software that is included.
If you use "special software combinations", you are on your own.

And especially the nvidia driver is not tested, nor supported, by openSUSE.
It is explicitly *not* recommended to use it on Tumbleweed.

You may do so, but you are on your own.

You will have to reinstall it after cerain updates as mentioned, and it may not even work because it may not support the latest kernel or Xorg versions.

But I already told you this half a year ago.
And it's unrelated to SDDM or KDE at all.

> > is just "cosmetical".
> 
> I imagine that the added destructor can prevent further hiccups, can't it?

Yes, and it has been done.
But it won't fix the problem that Xorg fails to start, it will (or should) only fix SDDM's segfault.
Nothing more can be done from SDDM's side.

Oh, and it would probably be a nice gesture from your side if you re-checked the other displaymanagers you filed bug reports about (see comment#2), and close those bug reports yourself if they work after you fixed your nvidia installation.

I very much doubt that all (or anyone) of them are broken... ;-)

(In reply to Wolfgang Bauer from comment #8)
> Tumbleweed is tested, but only the software that is included.
> If you use "special software combinations", you are on your own.

Not completely. - It took a while until the added destructor became also available by the official installation repository for software packages.


> I very much doubt that all (or anyone) of them are broken... ;-)

The software situation can change further after corresponding updates.
Good and bad surprises can still happen as usual.

(In reply to Markus Elfring from comment #9)
> (In reply to Wolfgang Bauer from comment #8)
> > Tumbleweed is tested, but only the software that is included.
> > If you use "special software combinations", you are on your own.
> 
> Not completely. - It took a while until the added destructor became also
> available by the official installation repository for software packages.

Whatever.

The SDDM crash is still secondary (and unrelated to the nvidia driver), and it should be fixed now.

No further discussion needed (or wanted from my side).

> > I very much doubt that all (or anyone) of them are broken... ;-)
> 
> The software situation can change further after corresponding updates.
> Good and bad surprises can still happen as usual.

Sorry, but that's irrelevant here.
Please close your bug reports if they are no longer relevant, thanks.

And in the end it all boils down to *your* nvidia installation I suppose, which we cannot test anyway.