Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Segfault on SDDM start
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Desktop Environments
View previous topic :: View next topic  
Author Message
AndrewAmmerlaan
Apprentice
Apprentice


Joined: 25 Jun 2014
Posts: 162
Location: Lent

PostPosted: Wed Jul 03, 2019 7:14 am    Post subject: Segfault on SDDM start Reply with quote

This has been driving me nuts for some time.

Sometimes SDDM will not respond to anything at all after it has started, and sometimes it will work just fine. There really is no predicting it. The cursor is visible and can be moved, but I can't click anything or type my password.
I've been looking at the xorg log from a working session and a frozen one and they are exactly identical (frozen: http://dpaste.com/2KXVY45 working: http://dpaste.com/1QEQBZ9).

dmesg shows some interesting lines however:
Code:
[   13.354477] elogind-daemon[3077]: New session c1 of user sddm.
[   14.543163] QSGRenderThread[3959]: segfault at 8 ip 00007f439a2fd873 sp 00007f4362de2470 error 4 in libQt5Gui.so.5.12.3[7f4399fda000+352000]
[   14.543167] Code: fd 53 4c 8b 2f 41 8b 4d 20 85 c9 74 2e 89 d0 41 89 d4 31 d2 f7 f1 49 8b 45 08 49 89 f6 48 8d 2c d0 48 8b 5d 00 49 39 dd 74 11 <44> 3b 63 08 74 17 48 89 dd 48 8b 1b 49 39 dd 75 ef 5b 48 89 e8 5d
[   14.581737] elogind-daemon[3077]: Removed session c1.
[   35.687500] elogind-daemon[3077]: New session 1 of user root.
[  100.537405] elogind-daemon[3077]: Removed session 1.
[  101.366700] elogind-daemon[3077]: New session 1 of user sddm.
[  102.167546] QSGRenderThread[4083]: segfault at 7f1c40901254 ip 00007f1c26114cc1 sp 00007f1bef9e2cc8 error 4 in libc-2.29.so[7f1c2608d000+159000]
[  102.167549] Code: f0 0f 10 5c 16 e0 0f 11 07 0f 11 4f 10 0f 11 54 17 f0 0f 11 5c 17 e0 c3 48 39 f7 0f 87 8c 00 00 00 0f 84 28 ff ff ff 0f 10 26 <0f> 10 6c 16 f0 0f 10 74 16 e0 0f 10 7c 16 d0 44 0f 10 44 16 c0 49
[  102.205163] elogind-daemon[3077]: Removed session 1.
[  122.607034] elogind-daemon[3077]: New session 2 of user root.
[  126.926255] elogind-daemon[3077]: Removed session 2.
[  127.680350] elogind-daemon[3077]: New session 2 of user sddm.
[  135.665259] elogind-daemon[3077]: New session 3 of user andrew.
[  135.778957] elogind-daemon[3077]: Removed session 2.


Note that I had a frozen session directly after boot, restarted sddm and still had a frozen session, and then restarted sddm again after which it worked just fine.
It seems to be segfaulting in different executables, which is strange I think. I'll be keeping an eye on it to see if it segfaults somewhere else next time.

I somehow suspect that this might be related to the nvidia-drivers, they have been causing lots of strange (work-aroundable) issues (see my other post here: https://forums.gentoo.org/viewtopic-t-1092880-start-0.html)

Does anyone have any idea what on earth is going on here?

emerge --info: http://dpaste.com/1ZE7XR2
xorg-server-1.20.5
nvidia-drivers-430.26
gentoo-sources-5.1.15
_________________
OS: Gentoo KDE x86_64 (~amd64, 5.3.9-gentoo)
MB: MSI Z370-A PRO
CPU: Intel Core i7-8700K
GPU: NVIDIA GTX 1060 6GB & Intel UHD Graphics 630
SSD: Samsung 970 Pro 512GB
RAM: Crucial Ballistix 32GB DDR4-2400
Back to top
View user's profile Send private message
mike155
Veteran
Veteran


Joined: 17 Sep 2010
Posts: 1994
Location: Frankfurt, Germany

PostPosted: Wed Jul 03, 2019 11:55 am    Post subject: Reply with quote

Please go to https://bugs.gentoo.org and http://bugs.kde.org and search for similar bugs. Maybe someone else has already filed a bug for this problem?
Back to top
View user's profile Send private message
asturm
Developer
Developer


Joined: 05 Apr 2007
Posts: 7480
Location: Austria

PostPosted: Wed Jul 03, 2019 12:02 pm    Post subject: Reply with quote

SDDM is no KDE product, they have their own issue tracker.
_________________
backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic
Back to top
View user's profile Send private message
AndrewAmmerlaan
Apprentice
Apprentice


Joined: 25 Jun 2014
Posts: 162
Location: Lent

PostPosted: Wed Jul 03, 2019 12:28 pm    Post subject: Reply with quote

mike155 wrote:
Please go to https://bugs.gentoo.org and http://bugs.kde.org and search for similar bugs. Maybe someone else has already filed a bug for this problem?


I did that of course, closest thing I could find is this one: https://github.com/sddm/sddm/issues/1060 but it's different because they are describing a 30 second freeze that happens every time. While I only sometimes get a freeze, and if I do it will stay frozen until sddm is restarted.
_________________
OS: Gentoo KDE x86_64 (~amd64, 5.3.9-gentoo)
MB: MSI Z370-A PRO
CPU: Intel Core i7-8700K
GPU: NVIDIA GTX 1060 6GB & Intel UHD Graphics 630
SSD: Samsung 970 Pro 512GB
RAM: Crucial Ballistix 32GB DDR4-2400
Back to top
View user's profile Send private message
mike155
Veteran
Veteran


Joined: 17 Sep 2010
Posts: 1994
Location: Frankfurt, Germany

PostPosted: Wed Jul 03, 2019 1:03 pm    Post subject: Reply with quote

If you get a freeze: please log in from a remote machine and run top. Do you see a process which consumes 100% CPU?
Back to top
View user's profile Send private message
AndrewAmmerlaan
Apprentice
Apprentice


Joined: 25 Jun 2014
Posts: 162
Location: Lent

PostPosted: Wed Jul 03, 2019 1:55 pm    Post subject: Reply with quote

mike155 wrote:
If you get a freeze: please log in from a remote machine and run top. Do you see a process which consumes 100% CPU?


Nope, highest process only uses 1.3%, this process got killed as soon as I switched to a tty (so possibly related to X/sddm). Not sure what the name of the process was, my phone wasn't wide enough to show that column.

Also I should mention that as soon as I switch to a tty I can't switch back to sddm without restarting it, it will just show a black screen with a cursor.
_________________
OS: Gentoo KDE x86_64 (~amd64, 5.3.9-gentoo)
MB: MSI Z370-A PRO
CPU: Intel Core i7-8700K
GPU: NVIDIA GTX 1060 6GB & Intel UHD Graphics 630
SSD: Samsung 970 Pro 512GB
RAM: Crucial Ballistix 32GB DDR4-2400


Last edited by AndrewAmmerlaan on Wed Jul 03, 2019 5:17 pm; edited 1 time in total
Back to top
View user's profile Send private message
mike155
Veteran
Veteran


Joined: 17 Sep 2010
Posts: 1994
Location: Frankfurt, Germany

PostPosted: Wed Jul 03, 2019 3:19 pm    Post subject: Reply with quote

3 weeks ago, I installed a new version of Plasma. After that, my desktop froze when I started Wireshark. I saw a process which consumed 100% CPU. With a little help from asturm, I was able to create a backtrace and file a bug report. The bug was fixed by the KDE developers a couple of days later.

You may want to take a look at the the URLs below to see how we nailed down my bug:
  1. https://bugs.gentoo.org/688128
  2. https://bugs.kde.org/show_bug.cgi?id=408754
  3. https://wiki.gentoo.org/wiki/Debugging
You could try do do something similar. It might or might not work in your case.
Back to top
View user's profile Send private message
AndrewAmmerlaan
Apprentice
Apprentice


Joined: 25 Jun 2014
Posts: 162
Location: Lent

PostPosted: Wed Jul 03, 2019 5:08 pm    Post subject: Reply with quote

Thanks for the tip, I'll look into it.

I'm currently testing a possible solution I found on arch linux's reddit they suggest that sddm might be to fast in starting and/or the nvidia drivers to slow in loading. I disregard this at first because I figured that if this was the problem I should just add the nvidia, nvidia_modeset and nvidia_drm modules to /etc/conf.d/modules to make them load as early as possible, but that didn't change anything when I tried.
But I decided to try their suggestion of editing the sddm/xdm init file anyway. I added "sleep 5" just before the "/etc/X11/startDM.sh" line, and sddm loaded without freezing upon the next reboot. Then again that might be a coincidence since sddm only freezes sometimes, so I'll wait and see if it will freeze again on some other reboot.

Though I'm kinda confused why this would be any different then loading the modules early in /etc/conf.d/modules. When I tried that it complained that nvidia and nvidia_modeset were already loaded, it didn't complain about nvidia_drm, so that was apparently not already loaded by the kernel. Might it be that loading nvidia_drm early would have no effect because X or SDDM reload it when they start?
_________________
OS: Gentoo KDE x86_64 (~amd64, 5.3.9-gentoo)
MB: MSI Z370-A PRO
CPU: Intel Core i7-8700K
GPU: NVIDIA GTX 1060 6GB & Intel UHD Graphics 630
SSD: Samsung 970 Pro 512GB
RAM: Crucial Ballistix 32GB DDR4-2400
Back to top
View user's profile Send private message
AndrewAmmerlaan
Apprentice
Apprentice


Joined: 25 Jun 2014
Posts: 162
Location: Lent

PostPosted: Fri Jul 05, 2019 11:40 am    Post subject: Reply with quote

Alright, delaying the start of sddm did not work.

I followed the guide on the wiki's debugging page and reemerged sddm and glibc with the nostrip feature and the -ggdb cflag. I also enabled core dumps in the kernel. Now I just kept rebooting until I got a segfault, but now where is the coredump file?

Code:

andrew@andrew-gentoo-pc ~ % cat /proc/sys/kernel/core_pattern
core
andrew-gentoo-pc linux # ulimit -c
unlimited


It's not in /, /home/andrew, /root or /tmp, where is it?

[EDIT]
I tried running sddm in gdb, after a couple of run, kill cycles I got a black screen with only a cursor and a unresponsive keyboard.
ssh'ing into it shows me:
Code:
[  904.920518] pulseaudio[4101]: segfault at 60 ip 00007f9736c91a6f sp 00007ffe913211e0 error 4 in module-loopback.so[7f9736c8e000+6000]
[  904.920522] Code: 00 48 8d 0d 13 3b 00 00 56 ba 99 00 00 00 31 ff 31 c0 e8 54 c9 ff ff 48 83 c4 20 e8 1b c6 ff ff 0f 1f 00 48 8b 43 18 48 89 df <48> 8b 50 60 48 8b 43 20 48 8b 70 60 e8 e0 d8 ff ff 48 8b 43 20 48


:/ what's this...... now pulseaudio is segfaulting? And that somehow results in a black screen?

Did get a backtrace of this though but it doesn't look that helpful: http://dpaste.com/1KDQ08V
_________________
OS: Gentoo KDE x86_64 (~amd64, 5.3.9-gentoo)
MB: MSI Z370-A PRO
CPU: Intel Core i7-8700K
GPU: NVIDIA GTX 1060 6GB & Intel UHD Graphics 630
SSD: Samsung 970 Pro 512GB
RAM: Crucial Ballistix 32GB DDR4-2400
Back to top
View user's profile Send private message
mike155
Veteran
Veteran


Joined: 17 Sep 2010
Posts: 1994
Location: Frankfurt, Germany

PostPosted: Fri Jul 05, 2019 1:08 pm    Post subject: Reply with quote

Please tell us exactly what happend.
  1. You stared sddm in gdb? (Good!) How did you dod that? From a console? Or via ssh?

  2. That worked a couple of times and you could work with your machine?

  3. Then it failed and you got a black screen?

  4. You logged in via ssh?

  5. You saw the pulseaudio segfault? (Forget about that for a second)

  6. Your screen was still black?

  7. How exactly did you create the backtrace? Was the sddm process still running in gdb? Did you kill it with Ctrl-C? Or was the sddm process already terminated and you could enter 'bt' at the gdb prompt?
Back to top
View user's profile Send private message
AndrewAmmerlaan
Apprentice
Apprentice


Joined: 25 Jun 2014
Posts: 162
Location: Lent

PostPosted: Fri Jul 05, 2019 1:19 pm    Post subject: Reply with quote

I first tried restarting the system to get sddm to freeze, when it finally happend. I couldn't find the segfualts core dump file anywhere.

Then I tried running sddm through gdb a couple of times:
Code:
gdb sddm
run
kill
run
run (for some reason it would not run immediately after killing it)
kill
run
run
kill
etcetera

Then at some point sddm just gave me a black screen with a cursor. It didn't respond to ctrl-alt-f1 so I logged into ssh and found pulseaudio's segfault in dmesg. Screen remained black untill I did killall X. That returned me to the console where I ran backtrace within gdb to create the backtrace, which I logged to a file with 'set logging on somefile'. So sddm/X were already dead at this point.

---------------------------------[EDIT]----------------------------------------------------
Alright now I may have something useful. I seem to have trouble reproducing the original segfault if it is not the first time sddm has been started. Therefore, I removed xdm from the default runlevel, rebooted, and then ran sddm directly from the command line. I repeated this until I had a session where sddm froze and dmesg showed me:
Code:

[   23.071813] QSGRenderThread[3920]: segfault at 7 ip 00007f1d3045a1a6 sp 00007f1cf9965400 error 4 in libc-2.29.so[7f1d303f1000+159000]
[   23.071817] Code: 84 42 ff ff ff 0f 1f 80 00 00 00 00 4a 8d 14 e0 4c 8b 42 40 4d 85 c0 0f 84 2a ff ff ff 48 81 fb ff 03 00 00 0f 87 ea 01 00 00 <49> 8b 08 48 89 4a 40 42 fe 0c 2049 c7 40 08 00 00 00 00 0f 1f 80


When it finally happened, I found that sddm did not actually quit or die when it froze. The command kept running and I did not get my command prompt back. (This is probably also why I couldn't find the coredump file, it doesn't make one because sddm is not where the segfault occurs, It just freezes after something else segfaults.).

Anyway when it froze I switched back to tty1 and used the CTRL+\ shortcut to force it to coredump, it gave me the following backtrace:
Code:

Reading symbols from sddm...
Reading symbols from /usr/lib/debug//usr/bin/sddm.debug...
[New LWP 3853]
[New LWP 3854]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `sddm'.
Program terminated with signal SIGQUIT, Quit.
#0  0x00007f265c4c1393 in __GI___poll (fds=0x55f34e0ed8d0, nfds=10, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
29        return SYSCALL_CANCEL (poll, fds, nfds, timeout);
[Current thread is 1 (Thread 0x7f2659df6f80 (LWP 3853))]
(gdb) bt
#0  0x00007f265c4c1393 in __GI___poll (fds=0x55f34e0ed8d0, nfds=10, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
#1  0x00007f265b90015e in g_main_context_poll (priority=<optimized out>, n_fds=10, fds=0x55f34e0ed8d0, timeout=<optimized out>, context=0x55f34e0ca340) at /usr/src/debug/dev-libs/glib-2.58.3/glib-2.58.3/glib/gmain.c:4221
#2  g_main_context_iterate (context=context@entry=0x55f34e0ca340, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at /usr/src/debug/dev-libs/glib-2.58.3/glib-2.58.3/glib/gmain.c:3915
#3  0x00007f265b90027f in g_main_context_iteration (context=0x55f34e0ca340, may_block=may_block@entry=1) at /usr/src/debug/dev-libs/glib-2.58.3/glib-2.58.3/glib/gmain.c:3981
#4  0x00007f265cb0b280 in QEventDispatcherGlib::processEvents (this=0x55f34e0c99b0, flags=...) at kernel/qeventdispatcher_glib.cpp:422
#5  0x00007f265cab0a7b in QEventLoop::exec (this=this@entry=0x7ffe74f35300, flags=..., flags@entry=...) at ../../include/QtCore/../../src/corelib/global/qflags.h:140
#6  0x00007f265cab8f52 in QCoreApplication::exec () at ../../include/QtCore/../../src/corelib/global/qflags.h:120
#7  0x000055f34d3a301a in main (argc=<optimized out>, argv=0x7ffe74f354d8) at /usr/src/debug/x11-misc/sddm-0.18.1-r1/sddm-0.18.1/src/daemon/DaemonApp.cpp:138


Then I tried to restart sddm (by running the command manually) and was surprised to find that it segfaulted and coredumped immediately:
Code:

Reading symbols from sddm...
Reading symbols from /usr/lib/debug//usr/bin/sddm.debug...
[New LWP 3927]
[New LWP 3928]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `sddm'.
Program terminated with signal SIGABRT, Aborted.
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50        return ret;
[Current thread is 1 (Thread 0x7f2362626f80 (LWP 3927))]
(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x00007f2364c1a535 in __GI_abort () at abort.c:79
#2  0x00007f23650e1707 in qt_message_fatal (context=..., message=<synthetic pointer>...) at global/qlogging.cpp:1901
#3  QMessageLogger::fatal (this=this@entry=0x7ffcf29c2c30, msg=msg@entry=0x55d7ecc209c8 "Display server failed to start. Exiting") at global/qlogging.cpp:887
#4  0x000055d7ecbc468d in SDDM::Display::start (this=this@entry=0x55d7ed5e4890) at /usr/include/qt5/QtCore/qlogging.h:91
#5  0x000055d7ecc0643f in SDDM::Seat::createDisplay (this=0x55d7ed5fd770, terminalId=7) at /usr/src/debug/x11-misc/sddm-0.18.1-r1/sddm-0.18.1/src/daemon/Seat.cpp:82
#6  0x000055d7ecc0665d in SDDM::Seat::Seat (this=0x55d7ed5fd770, name=..., parent=<optimized out>) at /usr/src/debug/x11-misc/sddm-0.18.1-r1/sddm-0.18.1/src/daemon/Seat.cpp:48
#7  0x000055d7ecc0881d in SDDM::SeatManager::createSeat (this=0x55d7ed5e98f0, name=...) at /usr/src/debug/x11-misc/sddm-0.18.1-r1/sddm-0.18.1/src/daemon/SeatManager.cpp:121
#8  0x000055d7ecc08960 in SDDM::SeatManager::<lambda()>::operator() (__closure=0x55d7ed5e3aa0, __closure=0x55d7ed5e3aa0) at /usr/src/debug/x11-misc/sddm-0.18.1-r1/sddm-0.18.1/src/daemon/SeatManager.cpp:159
#9  QtPrivate::FunctorCall<QtPrivate::IndexesList<>, QtPrivate::List<>, void, SDDM::SeatManager::logindSeatAdded(const QString&, const QDBusObjectPath&)::<lambda()> >::call (arg=<optimized out>, f=...) at /usr/include/qt5/QtCore/qobjectdefs_impl.h:146
#10 QtPrivate::Functor<SDDM::SeatManager::logindSeatAdded(const QString&, const QDBusObjectPath&)::<lambda()>, 0>::call<QtPrivate::List<>, void> (arg=<optimized out>, f=...) at /usr/include/qt5/QtCore/qobjectdefs_impl.h:256
#11 QtPrivate::QFunctorSlotObject<SDDM::SeatManager::logindSeatAdded(const QString&, const QDBusObjectPath&)::<lambda()>, 0, QtPrivate::List<>, void>::impl(int, QtPrivate::QSlotObjectBase *, QObject *, void **, bool *) (which=<optimized out>, this_=0x55d7ed5e3a90,
r=<optimized out>, a=<optimized out>, ret=<optimized out>) at /usr/include/qt5/QtCore/qobjectdefs_impl.h:439
#12 0x00007f236530e01e in QtPrivate::QSlotObjectBase::call (a=0x7ffcf29c2e80, r=0x55d7ed5e98f0, this=0x55d7ed5e3a90) at ../../include/QtCore/../../src/corelib/kernel/qobjectdefs_impl.h:394
#13 QMetaObject::activate (sender=0x55d7ed5e9550, signalOffset=<optimized out>, local_signal_index=<optimized out>, argv=<optimized out>) at kernel/qobject.cpp:3776
#14 0x000055d7ecc0760f in SDDM::LogindSeat::canGraphicalChanged (this=<optimized out>, _t1=<optimized out>, _t1@entry=true) at src/daemon/sddm_autogen/include/SeatManager.moc:143
#15 0x000055d7ecc07ac3 in SDDM::LogindSeat::<lambda()>::operator() (__closure=0x55d7ed5e3ad0) at /usr/src/debug/x11-misc/sddm-0.18.1-r1/sddm-0.18.1/src/daemon/SeatManager.cpp:68
#16 QtPrivate::FunctorCall<QtPrivate::IndexesList<>, QtPrivate::List<>, void, SDDM::LogindSeat::LogindSeat(const QString&, const QDBusObjectPath&, QObject*)::<lambda()> >::call (arg=<optimized out>, f=...) at /usr/include/qt5/QtCore/qobjectdefs_impl.h:146
#17 QtPrivate::Functor<SDDM::LogindSeat::LogindSeat(const QString&, const QDBusObjectPath&, QObject*)::<lambda()>, 0>::call<QtPrivate::List<>, void> (arg=<optimized out>, f=...) at /usr/include/qt5/QtCore/qobjectdefs_impl.h:256
#18 QtPrivate::QFunctorSlotObject<SDDM::LogindSeat::LogindSeat(const QString&, const QDBusObjectPath&, QObject*)::<lambda()>, 0, QtPrivate::List<>, void>::impl(int, QtPrivate::QSlotObjectBase *, QObject *, void **, bool *) (which=<optimized out>, this_=0x55d7ed5e3ac0,
r=<optimized out>, a=<optimized out>, ret=<optimized out>) at /usr/include/qt5/QtCore/qobjectdefs_impl.h:439
#19 0x00007f236530e01e in QtPrivate::QSlotObjectBase::call (a=0x7ffcf29c3020, r=0x55d7ed5e9550, this=0x55d7ed5e3ac0) at ../../include/QtCore/../../src/corelib/kernel/qobjectdefs_impl.h:394
#20 QMetaObject::activate (sender=0x55d7ed5fdd90, signalOffset=<optimized out>, local_signal_index=<optimized out>, argv=<optimized out>) at kernel/qobject.cpp:3776
#21 0x00007f2365c94dcf in QDBusPendingCallWatcher::finished (this=<optimized out>, _t1=<optimized out>) at .moc/moc_qdbuspendingcall.cpp:158
#22 0x00007f2365c94edb in QDBusPendingCallWatcher::qt_static_metacall (_o=<optimized out>, _c=<optimized out>, _id=<optimized out>, _a=<optimized out>) at .moc/moc_qdbuspendingcall.cpp:94
#23 0x00007f236530edca in QObject::event (this=0x55d7ed5fdd90, e=<optimized out>) at kernel/qobject.cpp:1260
#24 0x00007f23652e1ebb in doNotify (receiver=0x55d7ed5fdd90, event=0x55d7ed5d6ba0) at ../../include/QtCore/../../src/corelib/kernel/qobject.h:142
#25 0x00007f23652e1f4f in QCoreApplication::notifyInternal2 (receiver=0x55d7ed5fdd90, event=0x55d7ed5d6ba0) at kernel/qcoreapplication.cpp:1060
#26 0x00007f23652e5265 in QCoreApplicationPrivate::sendPostedEvents (receiver=0x0, event_type=0, data=0x55d7ed5d5ee0) at kernel/qcoreapplication.cpp:1799
#27 0x00007f236533b863 in postEventSourceDispatch (s=0x55d7ed5e75c0) at kernel/qeventdispatcher_glib.cpp:276
#28 0x00007f236412ff62 in g_main_dispatch (context=0x55d7ed5dd340) at /usr/src/debug/dev-libs/glib-2.58.3/glib-2.58.3/glib/gmain.c:3182
#29 g_main_context_dispatch (context=context@entry=0x55d7ed5dd340) at /usr/src/debug/dev-libs/glib-2.58.3/glib-2.58.3/glib/gmain.c:3847
#30 0x00007f23641301f0 in g_main_context_iterate (context=context@entry=0x55d7ed5dd340, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at /usr/src/debug/dev-libs/glib-2.58.3/glib-2.58.3/glib/gmain.c:3920
#31 0x00007f236413027f in g_main_context_iteration (context=0x55d7ed5dd340, may_block=may_block@entry=1) at /usr/src/debug/dev-libs/glib-2.58.3/glib-2.58.3/glib/gmain.c:3981
#32 0x00007f236533b280 in QEventDispatcherGlib::processEvents (this=0x55d7ed5dc9b0, flags=...) at kernel/qeventdispatcher_glib.cpp:422
#33 0x00007f23652e0a7b in QEventLoop::exec (this=this@entry=0x7ffcf29c3440, flags=..., flags@entry=...) at ../../include/QtCore/../../src/corelib/global/qflags.h:140
#34 0x00007f23652e8f52 in QCoreApplication::exec () at ../../include/QtCore/../../src/corelib/global/qflags.h:120
#35 0x000055d7ecbc801a in main (argc=<optimized out>, argv=0x7ffcf29c3618) at /usr/src/debug/x11-misc/sddm-0.18.1-r1/sddm-0.18.1/src/daemon/DaemonApp.cpp:138


Now I'm unsure what any of this actually means, is the bug in the poll.c function?

[EDIT2]
Found the file it seems to be complaining about: https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/poll.c;h=1de2aa3c0f2dd162dd06810b3ab116cc180dc903;hb=HEAD but it seems to exist, so not sure why it complains about not finding it.
Also why would it sometimes work fine(be able to find the file) and sometimes freeze(not be able to find the file)? It makes no sense.

[EDIT3]
Aah maybe it has to do with the if statement in that file, it seems it gets the argument "timeout=-1" but then there is this "if (timeout >= 0)" statement where 'timeout_ts_p' is set. So if timeout is -1, it is unset, and this variable comes back in the return function so an empty variable would be sent back to whatever function called the poll function in the first place. Maybe that somehow causes a problem, but tbh, I have no idea, I don't know enough C for this. I'm a physicist not a programmer, I work almost enterily with python if I have to program anything.

[EDIT 4]
enabled debug use flag on related packages and recompiled glib with correct features, and replaced the backtrace above with a newer better version.
_________________
OS: Gentoo KDE x86_64 (~amd64, 5.3.9-gentoo)
MB: MSI Z370-A PRO
CPU: Intel Core i7-8700K
GPU: NVIDIA GTX 1060 6GB & Intel UHD Graphics 630
SSD: Samsung 970 Pro 512GB
RAM: Crucial Ballistix 32GB DDR4-2400
Back to top
View user's profile Send private message
AndrewAmmerlaan
Apprentice
Apprentice


Joined: 25 Jun 2014
Posts: 162
Location: Lent

PostPosted: Fri Jul 05, 2019 7:44 pm    Post subject: Reply with quote

Alright, since I now have what looks to me like a decent backtrace I have reported this issue on sddm's github bug tracking page: https://github.com/sddm/sddm/issues/1179
_________________
OS: Gentoo KDE x86_64 (~amd64, 5.3.9-gentoo)
MB: MSI Z370-A PRO
CPU: Intel Core i7-8700K
GPU: NVIDIA GTX 1060 6GB & Intel UHD Graphics 630
SSD: Samsung 970 Pro 512GB
RAM: Crucial Ballistix 32GB DDR4-2400
Back to top
View user's profile Send private message
Goverp
l33t
l33t


Joined: 07 Mar 2007
Posts: 805

PostPosted: Sat Jul 06, 2019 10:16 am    Post subject: Reply with quote

A totally uniformed suggestion: if you're using KDE as well as sddm, try changing the sddm theme from "breeze". I had a problem with Leave-Switch User taking me to an sddm screen with a non-functional keyboard, and found a bug discussion that said the problem was actually in the breeze theme.

As I say, totally uninformed, I've no idea if it's relevant to this situation, but it's pretty easy to try. I'm using "Elarun" theme, much nastier than breeze, but it seems to work OK.
_________________
Greybeard
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Desktop Environments All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum