D14302: Don't block forever in ensureKdeinitRunning

[Thiago Macieira]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20180724/8d5ac5ed/attachment.html>