VirtualGL

1.0.x didn't have that feature, so that's why it's not failing-- nothing 
there to fail.

The idle timeout is in seconds and is a 32-bit value.  It's multiplied 
by 1000 to get milliseconds and passed into TimerSet(), so in order to 
overrun that value, you'd need an idle timeout of more than 24 days.  I 
don't really understand your description of the problem below.  Can you 
clarify?

Also, didn't you write this code to begin with?


On 9/24/12 5:45 PM, Craig Ruff wrote:
> I belive that, possibly due to a 2's compliment wrap around issue, enabling the
> max-idle-timeout is starting to fail due to the current seconds past the epoch
> value.  Testing shows that the required value for max-idle-timeout is
> decreasing as time passes.  For example, with max-idle-timeout set to 93900
> seconds, passing from the seconds past the epoch value of 1348525877 to
> 1348525896, the behavior went from starting successfully to failing immediately
> at startup.  The log messages was:
>
> 24/09/2012 16:31:36 NOTICE: idle timeout set to 93900 seconds per system policy
>
>
> This would correspond to between:
>
> 1,348,619,677,000 and 1,348,619,696,000 milliseconds past the epoch.
>
> I don't have the time to track things down at the moment due to a
> the work commissioning a new data center, so I've had to disable
> the max-idle-timeout.
>
> This also is happenint in 1.1 beta, but not for a previous version of
> 1.0 something.
>

On Wed, Sep 26, 2012 at 01:36:07AM -0500, DRC wrote:
> The idle timeout is in seconds and is a 32-bit value.  It's multiplied 
> by 1000 to get milliseconds and passed into TimerSet(), so in order to 
> overrun that value, you'd need an idle timeout of more than 24 days.  I 
> don't really understand your description of the problem below.  Can you 
> clarify?
> 
> Also, didn't you write this code to begin with?

Not any of the timer code within the X server itself, just the call for
time idle timeout.  The timer code adds the absolute time to the relative
timeout value.  Today, with max-idle-timeout set to 1, it fails immediately:
Unfortunately, I don't have the time  to poke further.

26/09/2012 08:07:52 Using auth configuration file /etc/turbovncserver-auth.conf
...
26/09/2012 08:07:52 NOTICE: idle timeout set to 1 seconds per system policy
...
26/09/2012 08:07:52 VNC extension running!
Could not init font path element /usr/share/fonts/Speedo, removing from list!

Fatal server error:
TurboVNC server has been idle for 1 seconds.  Exiting.

On 9/26/12 9:12 AM, Craig Ruff wrote:
> Not any of the timer code within the X server itself, just the call for
> time idle timeout.  The timer code adds the absolute time to the relative
> timeout value.  Today, with max-idle-timeout set to 1, it fails immediately:
> Unfortunately, I don't have the time  to poke further.
>
> 26/09/2012 08:07:52 Using auth configuration file /etc/turbovncserver-auth.conf
> ...
> 26/09/2012 08:07:52 NOTICE: idle timeout set to 1 seconds per system policy
> ...
> 26/09/2012 08:07:52 VNC extension running!
> Could not init font path element /usr/share/fonts/Speedo, removing from list!
>
> Fatal server error:
> TurboVNC server has been idle for 1 seconds.  Exiting.


Isn't that the way it's supposed to behave?

Still not understanding why you think there's a bug.

On Wed, Sep 26, 2012 at 02:53:23PM -0500, DRC wrote:
> Isn't that the way it's supposed to behave?
> 
> Still not understanding why you think there's a bug.

Sorry, '1' was too small of a value to be a good example,
since it would timeout pretty much immediately.

Earlier in the week, we were seeing immediate failures when starting the
server with the timeout value set for 3 days in the future.  For what
ever reason, while troubleshooting it on Monday, the value seemed to be
related to a specific value of absolute time, and as wall clock time
passed I could reduce the timeout value accordingly to a smaller value
(still more than 1 day), and still see the failure.  I was able to
recreate this on both multiple RHEL 6.2 and OpenSUSE 12.1 systems
and multiple users saw the issue.

Today, strangely, things are working again.  Since it was so repeatable,
I assume there was/is an issue with the X server's timeout code and a
2s compliment overflow causing the timeout call back to be called
immediately when the idle timeout timer is set.  There might be a
range of values that triggers the problem.

On 9/26/12 3:23 PM, Craig Ruff wrote:
> Earlier in the week, we were seeing immediate failures when starting the
> server with the timeout value set for 3 days in the future.  For what
> ever reason, while troubleshooting it on Monday, the value seemed to be
> related to a specific value of absolute time, and as wall clock time
> passed I could reduce the timeout value accordingly to a smaller value
> (still more than 1 day), and still see the failure.  I was able to
> recreate this on both multiple RHEL 6.2 and OpenSUSE 12.1 systems
> and multiple users saw the issue.
>
> Today, strangely, things are working again.  Since it was so repeatable,
> I assume there was/is an issue with the X server's timeout code and a
> 2s compliment overflow causing the timeout call back to be called
> immediately when the idle timeout timer is set.  There might be a
> range of values that triggers the problem.

OK, I think I see the issue now.  All of the X timer stuff uses unsigned 
32-bit values to store the number of milliseconds since the epoch, but 
since these values are milliseconds and not seconds, they're going to 
wrap around to 0 every 49 days.  If the server was started near the end 
of one of these 49-day cycles but the idle timeout was set far enough 
into the future that it occurred in a new cycle, then the expiration 
time for the timer would wrap around and actually be a lower value than 
the current time, thus causing the server to exit.

Oddly, newer X server code bases don't fix this issue as much as they 
work around it by checking for a wrap-around and resetting all of the 
timers if one is detected.  Rather than do that, I just made the timers 
all 64-bit.

Patch has been checked into trunk.  I'm relying on you to test it, since 
I don't personally use the idle timeout feature.