Bug 567

Summary: Xorg Xprt starts to consume 100% CPU when being idle for some time
Product: xprint Reporter: Roland Mainz <roland.mainz>
Component: Server: OtherAssignee: Roland Mainz <roland.mainz>
Status: RESOLVED FIXED QA Contact:
Severity: blocker    
Priority: high CC: alan.coopersmith, jay.hobson, roland.mainz
Version: unspecified   
Hardware: x86 (IA32)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
Patch for 2004-04-26-trunk none

Description Roland Mainz 2004-04-28 06:52:46 UTC
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:myacct@cvs.freedesktop.org:/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
:50)
... 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
Comment 1 Roland Mainz 2004-04-28 06:53:55 UTC
Alan:
Any idea what is going wrong here ?
Comment 2 Roland Mainz 2004-04-28 11:20:32 UTC
jhobson:
I tried your suggestion with DPMS:
1. Using "xset" does not work because the Xprt server does not announce the DPMS
extension
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") ... ;-(
Comment 3 Roland Mainz 2004-04-28 21:24:51 UTC
I managed to compile a Xprt binary with |#define BuildDPMS NO| - the problem
still happens...

... then I tried to turn everything OFF which may be responsible for the
problem:
-- 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 ?
Comment 4 Alan Coopersmith 2004-04-29 13:19:43 UTC
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 
Linux equivalents.
Comment 5 Roland Mainz 2004-04-30 05:53:22 UTC
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
minute.
Comment 6 Alan Coopersmith 2004-04-30 06:13:32 UTC
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.)
Comment 7 Roland Mainz 2004-04-30 06:38:18 UTC
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 
> client
> 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... :)
Comment 8 Roland Mainz 2004-04-30 09:57:37 UTC
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.
Comment 9 Roland Mainz 2004-04-30 10:00:07 UTC
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
done
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
done
Mailing the commit message to xorg-commit@pdx.freedesktop.org...

... marking bug as FIXED.

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.