Created attachment 31122 [details] xdm log after segfault I commented DisplayManager.requestPort: 0 out in /etc/X11/xdm/xdm-config in order to use XDMCP. This works fine, except that I can only log in once or have one failed login. After that no new login screen appears. (xdm is still running). It worked fine before I used XDMCP. For these logs I started xdm and tried to log in with an empty username and an empty password. The login screen vanished and didn't appear again (like it should). versions: kernel26 2.6.31.5 glibc 2.11 libxdmcp 1.0.3 xorg-xdm 1.1.9 What I have in messages.log: Nov 12 01:24:35 haljo kernel: xdm[14074]: segfault at 7fe700000001 ip 00007fe760be5cbe sp 00007fff70bcd7a0 error 4 in libc-2.11.so[7fe760ba0000+14d000] I will attach xdm.log and a backtrage generated with "bt full" after compiling glibc, libxdmcp and xorg-xdm with -ggdb. The important part in xdm.log might be: xdm error (pid 14074): pam_authenticate failure: User not known to the underlying authentication module xdm error (pid 14069): Unknown session exit code 2816 from process 14074 XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":0.0" after 68 requests (57 known processed) with 0 events remaining. XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":0.0" after 85 requests (81 known processed) with 0 events remaining.
Created attachment 31123 [details] backtrace: gdb "bt full" with -ggdb in glibc,libxdmcp and xorg-xdm This is the backtrace I could gather from the running xdm right after the segfault.
I am using Arch Linux and for xorg-xdm: ./configure --prefix=/usr \ --disable-xdm-auth \ --disable-static \ --with-xdmconfigdir=/etc/X11/xdm \ --with-xdmscriptdir=/etc/X11/xdm \ CPPFLAGS="$CPPFLAGS -ggdb" \ --with-pixmapdir=/usr/share/xdm/pixmaps
Okay - the segfault in /var/log/messages might be something different. I set DisplayManager.requestPort: 0 and I can login again and again. Obviously XDMCP is not working then. However, there is still the same segfault in /var/log/messages. This might be some cause that XDMCP is not working but the segfault is NOT triggered by the requestPort option. It possible that a fix of https://bugs.freedesktop.org/show_bug.cgi?id=24588 or https://bugs.freedesktop.org/show_bug.cgi?id=24589 also fixes my problem.
The backtrace does not appear to be from the segfaulted process. Be careful to note which xdm process is which - there's normally a master xdm daemon/parent, and a child xdm process per display.
My mistake. The backtrace is from the master xdm. I was able to create a backtrace from a core dump after I leave the window manager. This looks nearly identical to the one in https://bugs.freedesktop.org/show_bug.cgi?id=24589 I added it there. The xdm.log is also a bit different from the one attached here. Then I have a different segfault after I enter wrong user information. I could not get a core dump for this one for some reason. The xdm.log here is for this case (with the pam_authenticate failure) The slave (-:0) is the one segfaulting and throwing the pam_authenticate failure: xdm error (pid 2596): pam_authenticate failure: User not known to the underlying authentication module The master (xdm) is giving: xdm error (pid 2591): Unknown session exit code 2816 from process 2596 I don't know why I didn't get a core dump. There should be enough space left (2 Gig) and I also set ulimit -aH unlimited, ulimit -aS unlimited and /proc/sys/fs/suid_dumpable = 1
Do you still get this crash with xdm 1.1.10?
Hm - trying again with: glibc 2.11.1-2 kernel26 2.6.32.10-1 libxdmcp 1.0.3-1 xorg-xdm 1.1.9-3 I can't reproduce the bug anymore. This also doesnt change with a new compilation of xorg-xdm 1.1.10 Maybe I missed another configuration option that was relevant or this was dependendent to something else than xdm.. I didn't try it in between so I don't have a clue what of these many changes on my system could have fixed this issue. Can't reproduce it anymore -> close it
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.