(timeout in ms vs. XSyncValueSubtract) Frozen client, found cause, need advise for fix

[Daniel Martin]

Am 22.02.2017 11:24 schrieb "Daniel Martin" <consume.noise at gmail.com>:

On 21 February 2017 at 17:48, walter harms <wharms at bfs.de> wrote:
> Am 20.02.2017 10:55, schrieb Daniel Martin:
>> What happens is:
>> - ServertimeBlockHandler() forwards a _big_ unsigned timeout to
>> AdjustWaitForDelay()
>> - AdjustWaitForDelay() takes this _big_ unsigned as int and it becomes
>> a negative value
>> - the negative value ends up as timeout in ospoll_wait() as parameter
>> to epoll_wait()
>>> epoll_wait() blocks due to the negative timeout
>>
>> XSyncValueSubtract() doesn't handle unsigned wraps. That's why we get
>> a big unsigned from ServertimeBlockHandler(). Just imagine two
>> XSyncValues:
>>     a = {.hi=1, .lo=1} and b = {.hi=0, lo=.2}.
>> The result of XSyncValueSubtract(a - b) is
>>     presult = {.hi=0, .lo=4294967295},
>> where I would expect
>>    presult = {.hi=0, .lo=9}.
>>
>> If .lo=4294967295 is wrong and .lo=9 is what we want, could anyone
>> provide a fix, please? I'm to dumb for the (binary?) arithmetic atm.
>> (And if it is wrong, did I just uncovered an ancient bug?)
>>
>
> XSyncValueSubtract is doing as expected,
> XSyncValue is the simulation of 64bitvalues on 32bit.
> see this in hex:
>  100000001
> -000000002
>  0FFFFFFFF = 4294967295 in .lo

If XSyncValueSubtract is correct as is, then I would say, that it is
not what we want in ServertimeBlockHandler().
At that point we handle XSyncValues like a struct timeval, though .lo
not being in usec, but ms. So, every .lo < 0 or > 999 is wrong.


That's wrong.  Ignore this.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.x.org/archives/xorg-devel/attachments/20170222/3b5b843a/attachment.html>