thiago added a comment.
> timer = {t1 = 9223372036854775807, t2 = 0, type = 1}
This is indeed Forever. How did it get there?
I showed in my debug session that the QDeadlineTimer is passed zero, and then
it does initialise properly. So I'm now beginning to question the compiler.
Specifically, this line:
QDeadlineTimer timer(qMax(timeout, -1)); // QDT only takes -1 as
"forever"
Is it possible that the compiler miscompiled qMax and caused a value of -1 to
be passed?
Alternatively, could timeout be -1? The call site is (before your patch):
if (!lock.tryLock()) {
Which should get the default value of 0. Could it be getting -1 somehow?
Maybe your distribution patched Qt?
Can you provide the disassembly of those two functions? Just run "disass" in
gdb from those two frames and paste here.
> In D14302#297119 <https://phabricator.kde.org/D14302#297119>, @thiago wrote:
>
>> No, because your statement is incorrect. setPreciseRemainingTime **does**
assign to t1:
>>
>> t1 += secs + toSecsAndNSecs(nsecs).first;
>>
>
>
> Yes, but this is assuming t1 = 0, I mean, it is not t1 = secs.... (not with
+=).
Wrong line. It does assign here:
*this = current(timerType);
And even if it didn't, the value in the timer is very specific (t1 ==
INT64_MAX and t2 == 0). The chance of getting that from uninitialised data is
too small to be considered.
REPOSITORY
R271 KDBusAddons
REVISION DETAIL
https://phabricator.kde.org/D14302
To: jtamate, dfaure, #frameworks, thiago
Cc: kde-frameworks-devel, michaelh, ngraham, bruns
