| Summary: | X11 connection hangs when time/clock on the client is stepped backwards | ||
|---|---|---|---|
| Product: | XCB | Reporter: | no where <nopwhere> |
| Component: | Library | Assignee: | xcb mailing list dummy <xcb> |
| Status: | RESOLVED INVALID | QA Contact: | xcb mailing list dummy <xcb> |
| Severity: | normal | ||
| Priority: | medium | ||
| Version: | unspecified | ||
| Hardware: | Other | ||
| OS: | FreeBSD | ||
| URL: | http://www.freebsd.org/cgi/query-pr.cgi?pr=167646 | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
|
Description
no where
2009-08-15 03:18:40 UTC
A couple of clarifications: - When you say "When the time on the client is stepped backwards", do you imply that the X server ran on a separate system (on which time didn't go backward), or on the same system? - Do other X programs hang, or just xload and xterm? For instance, xlogo, or on the other end of the complexity spectrum some "desktop" application? - Since I don't know the behavior of setting the clock on FreeBSD: when you step the clock backward, do calls to nanosleep or select or similar still take the right amount of time? I would imagine so, but I want to make sure. It seems highly unlikely to me that this bug would lie in XCB. It seems more likely that something above XCB gets confused by time going backward. XCB itself shouldn't care at all. ad 1) Yes. Clients run on a system different from where the server runs. ad 2) I usually have only these two running (this is for remote system management), so I cannot say. But it happens regularly. ad 3) I don't know. But I can log in to the system (via telnet) or even start another xterm there remotely (using xon). So except for the X connections which were already established during the time set, everything else seems to work o.k. ad 4) That might be true. I only filed this with xcb since to me it seemed the most likely place. Can you run with libX11 without XCB and verify that the bug disappears? This is probably the easiest way to verify that it is, in fact, an XCB bug. It could also be an Xlib bug, a server bug, or a bug up the stack somewhere. It's basically impossible for us to even try to debug it without more information. One of us could try to replicate it, although honestly I personally won't have time to work on that anytime soon. Before trying a different version of libX11, please attach to one of the hung programs with gdb and provide us with a backtrace. It would help to know *where* the programs hang. Like Josh, it's hard for me to imagine how this could be an XCB bug. But when we see what's hanging we'll have a better idea. O.k. I tried to dig a little deeper, and I am sorry to report that I most likely misfiled this bug report. There seems to be some interaction between FreeBSD's IPv6 stack and setting the date, as even a simple telnet connection was affected (I am running most stuff over IPv6, including X). So I'll close this report. Thank you very much for jumping on this so quickly and setting me on the right track. (In reply to comment #5) > O.k. I tried to dig a little deeper, and I am sorry to report that I most > likely misfiled this bug report. There seems to be some interaction between > FreeBSD's IPv6 stack and setting the date, as even a simple telnet connection > was affected (I am running most stuff over IPv6, including X). Wow. Just for curiosity's sake (and the sake of future searches), if you file this as a bug report with FreeBSD, please do add a link to that bug in this one. > So I'll close this report. > > Thank you very much for jumping on this so quickly and setting me on the right > track. No problem. Thanks for following up and digging further. Related FreeBSD bug: http://www.freebsd.org/cgi/query-pr.cgi?pr=167646 |
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.