2004-04-27-trunk Xorg Xprt on SuSE Linux 8.2 starts to consume 100% CPU when
being idle for some time (~10-15mins).
Steps to reproduce:
% export CVSROOT=:ext:email@example.com:/cvs/xorg
% export CVS_RSH=ssh
% cvs -z9 checkout -P xc
% cd xc/
% time nice make World 2>&1 | tee -a buildlog.log
% make install DESTDIR=/tmp/xptestinstall006 2>&1 | tee -a ../install.log
% cd programs/Xserver
% (export LD_LIBRARY_PATH=$PWD/../../exports/lib/ ; export
XPCONFIGDIR=/tmp/xptestinstall006/etc/X11/xserver ; ./Xprt -ac -audit 4 -core
... and then wait ~10-15 minutes.
After that Xprt starts madly to consume 100% ... at sample stack trace can be
found in http://pdx.freedesktop.org/cgi-bin/bugzilla/show_bug.cgi?id=542#c32
Any idea what is going wrong here ?
I tried your suggestion with DPMS:
1. Using "xset" does not work because the Xprt server does not announce the DPMS
2. Trying "Xprt -dpms ..." or "Xprt dpms ..." has no effect on the problem
3. Compiling without DPMS support ended in bug 570 ("Build with |#define
BuildDPMS NO| fails") ... ;-(
I managed to compile a Xprt binary with |#define BuildDPMS NO| - the problem
... then I tried to turn everything OFF which may be responsible for the
-- snip --
#define BuildXIE NO
#define BuildDBE NO
#define BuildXKB NO
#define BuildRECORD NO
#define BuildDPMS NO
#define BuildXF86VidModeExt NO
#define BuildXInputExt NO
#define BuildScreenSaverExt NO
#define BuildXvExt NO
-- snip --
... but the problem did not go away.
Any ideas how we should proceed ?
Is the builtin screensaver off ("xset s 0")?
Otherwise I'd normally suggest using pstack, truss, or dbx trace to see what it's
doing when it's running away, but those are Solaris tools, and I don't know the
Alan Coopersmith wrote:
> Is the builtin screensaver off ("xset s 0")?
Using "xset" may not have any affect since the Xserver usually resets itself
after the last client exists (which affects Xprt, too).
... but your're right... the builtin screensaver is causing the problem.
I tried it with % Xprt -s 10000 ... # and the problem did not occur within the
last hour, trying to use % Xprt -s 1 ... # caused the problem to appear after a
Well yes - that's what xlogo is for - to keep the server from resetting while
you're testing things like this. 8-)
(And actually, for reasons I don't remember, the Solaris Xprt actually doesn't
reset every time the last client connects. I think it may have had something
to do with clients trying to connect in the split second between the last client
disconnect and the server reset, and getting their connection to the server
unceremoniously cut off.)
Alan Coopersmith wrote:
> Well yes - that's what xlogo is for - to keep the server from resetting while
> you're testing things like this. 8-)
Maybe that's the reason why CDE2.x has this dtprint deamon... :) ... I was
wondering what this thing is doing... :)
> (And actually, for reasons I don't remember, the Solaris Xprt actually doesn't
> reset every time the last client connects. I think it may have had something
> to do with clients trying to connect in the split second between the last
> disconnect and the server reset, and getting their connection to the server
> unceremoniously cut off.)
Uhm... can you open a bug and attach the patch for that, please ? That would be
a nice-to-have thing for the Xorg Xprt... :)
Created attachment 251 [details] [review]
Patch for 2004-04-26-trunk
The patch is only a workaround but I don't have a better idea how to fix this.
IMO it would be nice if the whole internal screensaver code could be #ifdef'ed
out since it is not used for Xprt... but I guess that's not possible since that
code is shared between multiple Xservers in the same build.
Patch checked-in (incl. fixed bugid number in Changelog) ...
Checking in xc/ChangeLog;
/cvs/xorg/xc/ChangeLog,v <-- ChangeLog
new revision: 1.13; previous revision: 1.12
Checking in xc/programs/Xserver/Xprint/Init.c;
/cvs/xorg/xc/programs/Xserver/Xprint/Init.c,v <-- Init.c
new revision: 1.3; previous revision: 1.2
Mailing the commit message to firstname.lastname@example.org...
... marking bug as FIXED.