Bugzilla Bug 10486

Emerge build: xfree-4.2.1.ebuild
make.conf cflags=march=pentium3 -03 -pipe(used to build my entire system).

I emerged xfree, and setup xdm to process remote xdmcp requests(I commented out
Display.requestPort in xdm-config & enabled direct/broadcast xdmcp access to
everyone("*") in Xaccess).

I startup xdm in debug mode, and all goes ok with the following last statements
being printed on my linuxbox: 

"creating socket 177
Created chooser socket 5
WaitForSomething"

Now I start-up my remote x-server(Xwin32-5.1 running on Windows XP) and enable
xdmcp broadcast. I get nothing(no chooser or login window like I normally get).
 After couple of minutes or so , I get a message within xwin32 logs as "XDM: too
many retransmissions".

Looking at my Linuxbox, a couple of lines have been spewed out by xdm: something
like "select returns 1" and "request 1 1 1"(or if I'm using indirect
xdmcp..."Indirect request"). Aside from those few lines I get _nothing_ else,
and "WaitForSomething" doesn't even appear again.  I then found out xdm is
hogging 99.9% of my cpu after recieving the request, where I can't sigterm it,
but only sigkill it.

I did a sigabrt on it to generate a core dump. And this is the rough output I
get from the gdb bt:
13 - __libc_start_main
12 - main()
11 - WaitForSomething()
10 - SendFailed()
09 - SendFailed()
08 - Willing()
(following from /lib/libc.so.6)
07 - fgets ()
06 - _IO_getline()
05 - _IO_getline_info()
04 - __uflow()
03 - _IO_default_uflow()
02 - _IO_new_file_underflow()
01 - __DTOR_END__()
00 - read()

I don't know why XDM is sucking so much CPU and not doing anything. I've tried
the same configuration using RH8.0, RH7.3 and RH7.2, and for all those cases xdm
worked for me with xwin-32. Thinking the problem has to do with my cflags, I
commented the entry out of my make.conf and compiled xfree-4.2.1 again: same
thing.  Then I went down to xfree-4.2.0-r12.ebuild, and again same problem.

Could it be a gcc problem? Don't know.  I will try to provide more information
if neccessary.

Regards,

Kashif

Forgot one thing: XDM doesn't spit out any info into its log.

Ok, I solved(actually worked around) the bug I reported.  The problem is when
XDM executes the default DisplayManager.willing entry in xdm-config: "su nobody
-c /usr/X11R6/lib/X11/xdm/Xwilling", user nobody doesn't have a valid
interpreter(it's set to /bin/false in passwd).  So the whole su statement
returns 1 with no output on stdout.  I haven't looked at the xdm source code,
but my guess is that xdm *assumes* it will recieve some output on stdout and
just waits in some busy loop on a non-blocking read.

You don't encounter such problems on redhat systems, because /sbin/nologin is
mapped to user nobody on login, which results in the message: "This account is
currently not available." in your chooser window.

Fix: Remove the 'su nobody -c' part, or just leave a blank entry for
DisplayManager.willing(resulting in "Willing to manage" in your chooser window).

Real fix: Some xdm hacker should look into Willing() and handle case where no
output is recieved.

Good to hear you got a work around.  I feel though that we should not close
this until I get the time to really fix it.  Some support in the future
to get this resolved will be appreciated.  I do however need to resolve some
other issues, so it can be a while before I get to it ...

Ok, I'll investigate the exact reason why xdm hogs cpu when it recieves no
stdout from executing the willing program.  Hopefully I can fix it, at which
time I'll post the patch.

Kashif

Same problem here with XFree version 4.3.0-r1.

Removing the 'su nobody' stuff from xdm-config
does not help at all.

tbekel@shimanto tbekel $ emerge info
Portage 2.0.47-r10 (default-x86-1.4, gcc-3.2.2, glibc-2.3.2-r0)
=================================================================
System uname: 2.4.20 i686 Pentium III (Coppermine)
GENTOO_MIRRORS="ftp://ftp.fhh.opensource-mirror.de/pub/gentoo.org ftp://sunsite.rwth-aachen.de/pub/Linux/gentoo http://distro.ibiblio.org/pub/linux/distributions/gentoo http://gentoo.oregonstate.edu/ http://www.ibiblio.org/pub/Linux/distributions/gentoo"
CONFIG_PROTECT="/var/qmail/control /usr/kde/2/share/config /usr/kde/3/share/config /usr/X11R6/lib/X11/xkb /usr/kde/3.1/share/config /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/config /etc"
CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d"
PORTDIR="/usr/portage"
DISTDIR="/usr/portage/distfiles"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR_OVERLAY=""
USE="x86 oss crypt cups gnome libg++ mikmod ncurses spell xml2 gdbm berkdb slang arts svga guile gpm tcpd pam libwww python esd imlib oggvorbis motif -3dnow acpi apm avi dvd encode fbcon gd gif gtk java jpeg kde -maildir mbox mmx mozilla mpeg mysql nls odbc opengl pcmcia pdflib perl png qt quicktime readline samba sdl ssl sse tcltk tetex tiff truetype X xmms xv zlib"
COMPILER="gcc3"
CHOST="i686-pc-linux-gnu"
CFLAGS="-march=pentium3 -O3 -pipe -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE"
CXXFLAGS="-march=pentium3 -O3 -pipe -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE"
ACCEPT_KEYWORDS="x86 ~x86"
MAKEOPTS="-j2"
AUTOCLEAN="yes"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
FEATURES="sandbox ccache"

Ran into this problem again and it took me quite some time to remember how I
solved it last time... just use a user with a valid shell instead of "nobody"
there and everything is fine. Maybe not a solution, but a nice workaround.

Updated the summary line to include "Xwilling" for the case someone wants to
enter a duplicate of this bug as I was just going to do...

Would be nice if this could be fixed with the next Xfree release.

I'm assuming this is fixed by now...please say if not.

Still looks to be a problem in modular X.

Fixed (finally) in xdm-1.0.3-r1, thanks!

Feel free to file an upstream bug at bugs.freedesktop.org in the xorg product
if you have any interest in getting the lack of handling of the no-output case
fixed. If you do, please CC me.

*** Bug 97091 has been marked as a duplicate of this bug. ***