Bug 1505 - Xorg server crash in WaitForSomething
Summary: Xorg server crash in WaitForSomething
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Server/General (show other bugs)
Version: git
Hardware: x86 (IA32) Linux (All)
: high normal
Assignee: Xorg Project Team
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-10-01 01:58 UTC by Felix Kühling
Modified: 2005-02-02 21:35 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments

Description Felix Kühling 2004-10-01 01:58:32 UTC
Yesterday the Xorg server crashed with Fatal Error:

WaitForSomething(): select: errno=22

This happened while I was running a remote Gnome session in an Xnest window
(using Xnest from DRI CVS if it matters). I added some more debug info in the
error message, so when it happens next time I'll have some more info:

                    FatalError("WaitForSomething(): select: errno=%d\n"
                    "\tMaxClients=%d, wt=%p, wt.tv_sec=%ld, wt.tv_usec=%ld\n",
                        selecterr, MaxClients, wt,
                        wt ? wt->tv_sec : 0, wt ? wt->tv_usec : 0);
Comment 1 Felix Kühling 2004-10-01 10:44:52 UTC
It happened again. This time just after logging into a local gnome session and
starting a gnome-terminal. So it has nothing to do with Xnest. It may be that
both happened when I started moving the mouse after a short break. This is the
output I got from my extended error message:

Fatal server error:
WaitForSomething(): select: errno=22
        MaxClients=256, wt=0xbffff698, wt.tv_sec=86, wt.tv_usec=654000

The timeout looks quite long to me, but is it enough to cause select to return
EINVAL? I'll try that out later.
Comment 2 Dave Airlie 2004-10-01 16:55:07 UTC
Can you try an reproduce with an older DRM? I think we do need those functions
stubbed out the way we had them as Keith pointed out...
Comment 3 Felix Kühling 2004-10-02 03:42:17 UTC
(In reply to comment #2)
> Can you try an reproduce with an older DRM? I think we do need those functions
> stubbed out the way we had them as Keith pointed out...

The problem is that this is hard to reproduce. I have got two server crashes in
three days now. In order to be sure I'd have to run the old DRM for several
days. Or would it be enouogh evidence that I didn't have a single server crash
with Xorg CVS before the DRM updates? If someone else reported server crashes
with Jon's latest DRM that would make me much more confident.

Another thing I noticed since a few days ago is that two or three times the
gnome panel or window manager died and were restarted by the gnome session.
Yesterday emacs suddenly disappeared and in the terminal where I had started it
from I got a message like "Connection to Xserver :0.0 lost.". Could this be
related too?
Comment 4 Felix Kühling 2004-10-04 08:12:06 UTC
I got another crash (the 3rd one) an hour ago. This time I had added some more
debug code that checked if the bit of the DRM descriptor (always happens to be 8
for me) was set in any of the fdsets. It was not. So I'm a bit out of ideas
right now. I also read some kernel code and it looks like it just ignores files
for which no poll fop is available. So I doubt this is related to Jon's kernel
changes. I'll run another CVS update now and recompile and see if that helps.
Comment 5 Roland Scheidegger 2004-10-25 14:44:44 UTC
I got the same crash 3 or 4 times since the last week (e.g. same
WaitForSomething(): select: errno=22 error message). And I also saw programs
randomly dying (kwin, kicker) for no apparent reason. Only local session.
I can't be sure though that my crashes are not my own fault, as I often do
"live" updates on dri drivers (e.g. just copy r200_dri.so with
--remove-destination over while the server is running), which has worked well in
the past but I'm not sure if it's actually safe.
Comment 6 Felix Kühling 2005-02-03 16:35:53 UTC
This was fixed in DRM a long time ago. Closing.


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.