Re: Re: KDE CI: Frameworks » kio » kf5-qt5 WindowsMSVCQt5.11 - Build # 17 - Still Failing!
On Wed, Sep 19, 2018 at 7:25 AM Ben Cooksley wrote: > > On Wed, 19 Sep 2018, 02:50 David Faure, wrote: >> >> Hmm So we need to kill it? > > > Except regular kill doesn't work. It's immune to that. > > Process Explorer (Sysinternals) and Task Manager (built in) can kill it > though, not sure how though. > > The solutions I can see in this case are: > a) Don't do D-Bus on Windows (there are many arguments to say it doesn't > belong there at all) > > b) Disable KSSLD on Windows (we would want to use the system certificate > store anyway, so we don't need our own infrastructure) Any updates on this? On another note, if Qt knows this part of Windows is broken, why is it even trying to spin down a thread when they know it's just going to shoot themselves in the foot? > > Cheers, > Ben > >> Regards, Ben >> ------ Forwarded Message ------ >> >> Subject: Re: KDE CI: Frameworks » kio » kf5-qt5 WindowsMSVCQt5.11 - Build # >> 17 >> - Still Failing! >> Date: mardi 18 septembre 2018, 16:09:33 CEST >> From: Thiago Macieira >> To: David Faure >> >> On Tuesday, 18 September 2018 00:16:50 PDT you wrote: >> > Hi Thiago, >> > >> > this looks like another issue with QtDBus using a separate thread, a >> > deadlock on shutdown, on Windows. I remember seeing discussions about that >> > in the past, I thought it was fixed? Maybe not in this particular case... >> >> It's not. Windows has a known design mistake in shutting down threads that >> they can't fix. And so can't we. >> >> -- >> Thiago Macieira - thiago.macieira (AT) intel.com >> Software Architect - Intel Open Source Technology Center >> >> - >> -- >> David Faure, fa...@kde.org, http://www.davidfaure.fr >> Working on KDE Frameworks 5 >> >> >>
Re: Re: KDE CI: Frameworks » kio » kf5-qt5 WindowsMSVCQt5.11 - Build # 17 - Still Failing!
On Wed, 19 Sep 2018, 02:50 David Faure, wrote: > Hmm So we need to kill it? > Except regular kill doesn't work. It's immune to that. Process Explorer (Sysinternals) and Task Manager (built in) can kill it though, not sure how though. The solutions I can see in this case are: a) Don't do D-Bus on Windows (there are many arguments to say it doesn't belong there at all) b) Disable KSSLD on Windows (we would want to use the system certificate store anyway, so we don't need our own infrastructure) Cheers, Ben > -- Forwarded Message -- > > Subject: Re: KDE CI: Frameworks » kio » kf5-qt5 WindowsMSVCQt5.11 - Build > # 17 > - Still Failing! > Date: mardi 18 septembre 2018, 16:09:33 CEST > From: Thiago Macieira > To: David Faure > > On Tuesday, 18 September 2018 00:16:50 PDT you wrote: > > Hi Thiago, > > > > this looks like another issue with QtDBus using a separate thread, a > > deadlock on shutdown, on Windows. I remember seeing discussions about > that > > in the past, I thought it was fixed? Maybe not in this particular case... > > It's not. Windows has a known design mistake in shutting down threads that > they can't fix. And so can't we. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > - > -- > David Faure, fa...@kde.org, http://www.davidfaure.fr > Working on KDE Frameworks 5 > > > >
Fwd: Re: KDE CI: Frameworks » kio » kf5-qt5 WindowsMSVCQt5.11 - Build # 17 - Still Failing!
Hmm So we need to kill it? -- Forwarded Message -- Subject: Re: KDE CI: Frameworks » kio » kf5-qt5 WindowsMSVCQt5.11 - Build # 17 - Still Failing! Date: mardi 18 septembre 2018, 16:09:33 CEST From: Thiago Macieira To: David Faure On Tuesday, 18 September 2018 00:16:50 PDT you wrote: > Hi Thiago, > > this looks like another issue with QtDBus using a separate thread, a > deadlock on shutdown, on Windows. I remember seeing discussions about that > in the past, I thought it was fixed? Maybe not in this particular case... It's not. Windows has a known design mistake in shutting down threads that they can't fix. And so can't we. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center - -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5
Re: KDE CI: Frameworks » kio » kf5-qt5 WindowsMSVCQt5.11 - Build # 17 - Still Failing!
Hi Thiago, this looks like another issue with QtDBus using a separate thread, a deadlock on shutdown, on Windows. I remember seeing discussions about that in the past, I thought it was fixed? Maybe not in this particular case... Cheers, David. On mardi 18 septembre 2018 09:08:18 CEST Ben Cooksley wrote: > Hi all, > > As this is a recurring issue on the CI system i've gone ahead and attached > a debugger to one of the "hung" instances of kioslave.exe. > > In this instance at least kioslave.exe is stuck in the destructor > for OrgKdeKSSLDInterface, cleaning up it's children. > In particular, it's trying to delete a QDBusServiceWatcher (doesn't this > need an event loop, which kioslave's don't have?) > > The trace is attached (sorry, couldn't figure out how to get MSVS to export > it in a textual format). > > If someone could take a look into this that would be appreciated. > > Cheers, > Ben -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5
Re: KDE CI: Frameworks » kio » kf5-qt5 WindowsMSVCQt5.11 - Build # 17 - Still Failing!
Hi all, As this is a recurring issue on the CI system i've gone ahead and attached a debugger to one of the "hung" instances of kioslave.exe. In this instance at least kioslave.exe is stuck in the destructor for OrgKdeKSSLDInterface, cleaning up it's children. In particular, it's trying to delete a QDBusServiceWatcher (doesn't this need an event loop, which kioslave's don't have?) The trace is attached (sorry, couldn't figure out how to get MSVS to export it in a textual format). If someone could take a look into this that would be appreciated. Cheers, Ben
KDE CI: Frameworks » kio » kf5-qt5 WindowsMSVCQt5.11 - Build # 17 - Still Failing!
BUILD FAILURE
Build URL
https://build.kde.org/job/Frameworks/job/kio/job/kf5-qt5%20WindowsMSVCQt5.11/17/
Project:
kf5-qt5 WindowsMSVCQt5.11
Date of build:
Tue, 18 Sep 2018 02:22:45 +
Build duration:
2 sec and counting
CONSOLE OUTPUT
Started by an SCM changeRunning in Durability level: MAX_SURVIVABILITY[Pipeline] nodeRunning on Windows Builder 2 in C:\CI\workspace\Frameworks\kio\kf5-qt5 WindowsMSVCQt5.11[Pipeline] {[Pipeline] timestamps[Pipeline] {[Pipeline] catchError[Pipeline] {[Pipeline] stage[Pipeline] { (Checkout Sources)[Pipeline] deleteDir[Pipeline] }[Pipeline] // stage[Pipeline] }java.nio.file.FileSystemException: C:\CI\workspace\Frameworks\kio\kf5-qt5 WindowsMSVCQt5.11\build\autotests: The process cannot access the file because it is being used by another process. at sun.nio.fs.WindowsException.translateToIOException(Unknown Source) at sun.nio.fs.WindowsException.rethrowAsIOException(Unknown Source) at sun.nio.fs.WindowsException.rethrowAsIOException(Unknown Source) at sun.nio.fs.WindowsFileSystemProvider.implDelete(Unknown Source) at sun.nio.fs.AbstractFileSystemProvider.deleteIfExists(Unknown Source) at java.nio.file.Files.deleteIfExists(Unknown Source) at hudson.Util.tryOnceDeleteFile(Util.java:316) at hudson.Util.deleteFile(Util.java:272)Also: hudson.remoting.Channel$CallSiteStackTrace: Remote call to JNLP4-connect connection from artonis.kde.org/195.201.167.115:49678 at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1741) at hudson.remoting.UserRequest$ExceptionResponse.retrieve(UserRequest.java:357) at hudson.remoting.Channel.call(Channel.java:955) at hudson.FilePath.act(FilePath.java:1070) at hudson.FilePath.act(FilePath.java:1059) at hudson.FilePath.deleteRecursive(FilePath.java:1266) at org.jenkinsci.plugins.workflow.steps.DeleteDirStep$Execution.run(DeleteDirStep.java:77) at org.jenkinsci.plugins.workflow.steps.DeleteDirStep$Execution.run(DeleteDirStep.java:69) at org.jenkinsci.plugins.workflow.steps.SynchronousNonBlockingStepExecution$1$1.call(SynchronousNonBlockingStepExecution.java:50) at hudson.security.ACL.impersonate(ACL.java:290) at org.jenkinsci.plugins.workflow.steps.SynchronousNonBlockingStepExecution$1.run(SynchronousNonBlockingStepExecution.java:47) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748)Caused: java.io.IOException: Unable to delete 'C:\CI\workspace\Frameworks\kio\kf5-qt5 WindowsMSVCQt5.11\build\autotests'. Tried 3 times (of a maximum of 3) waiting 0.1 sec between attempts. at hudson.Util.deleteFile(Util.java:277) at hudson.FilePath.deleteRecursive(FilePath.java:1303) at hudson.FilePath.deleteContentsRecursive(FilePath.java:1312) at hudson.FilePath.deleteRecursive(FilePath.java:1294) at hudson.FilePath.deleteContentsRecursive(FilePath.java:1312) at hudson.FilePath.deleteRecursive(FilePath.java:1294) at hudson.FilePath.access$1600(FilePath.java:211) at hudson.FilePath$DeleteRecursive.invoke(FilePath.java:1272) at hudson.FilePath$DeleteRecursive.invoke(FilePath.java:1268) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:3084) at hudson.remoting.UserRequest.perform(UserRequest.java:212) at hudson.remoting.UserRequest.perform(UserRequest.java:54) at hudson.remoting.Request$2.run(Request.java:369) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at hudson.remoting.Engine$1.lambda$newThread$0(Engine.java:93) at java.lang.Thread.run(Unknown Source)[Pipeline] // catchError[Pipeline] emailextrecipients[Pipeline] emailext
