dotCover CLI hanging

Answered

Hello everyone, having a bit of a weirdness that has creeped up with my dotCover CLI on our Jenkins server.  We are running Jenkins 2.121.2 on Windows 2016 with nunit 3.8.0.0.  Everything has been going along fine for quite some time but now we are experiencing where dotCover seems to be stuck in a loop.  I have upgraded dotCover to 2018.1.3 and it is still showing the same behavior.  Enabling the logs in dotCover I see messages like the below repeating endlessly until kill the process.  

15:22:22.207 |V| CommunicationTools | BridgeThread:8 | Listener_GetNewStreamIds listenerId=45695865-aaf4-4d7e-8493-686ea38c5dfd
15:22:22.425 |V| CommunicationTools | BridgeThread:8 | Listener_GetNewStreamIds listenerId=45695865-aaf4-4d7e-8493-686ea38c5dfd
15:22:22.628 |V| CommunicationTools | BridgeThread:8 | Listener_GetNewStreamIds listenerId=45695865-aaf4-4d7e-8493-686ea38c5dfd
15:22:22.800 |V| CommunicationTools | BridgeThread:8 | Listener_GetNewStreamIds listenerId=45695865-aaf4-4d7e-8493-686ea38c5dfd
15:22:22.910 |V| CommunicationTools | BridgeThread:8 | Listener_GetNewStreamIds listenerId=45695865-aaf4-4d7e-8493-686ea38c5dfd
15:22:23.019 |V| CommunicationTools | BridgeThread:8 | Listener_GetNewStreamIds listenerId=45695865-aaf4-4d7e-8493-686ea38c5dfd
15:22:23.129 |V| CommunicationTools | BridgeThread:8 | Listener_GetNewStreamIds listenerId=45695865-aaf4-4d7e-8493-686ea38c5dfd

The only thing that changes each run is the listenerId.  I can look further up in the logs searching for that listenerId and I see these related logs entries.  

15:22:14.831 |V| CommunicationTools | BridgeThread:8 | Listener_Create endPoint=127.0.0.1:0 res=ok bindedEndPoint=127.0.0.1:57213 listenerId=45695865-aaf4-4d7e-8493-686ea38c5dfd
15:22:14.831 |V| Bridge | BridgeThread:8 | BridgeListen res=listen ipEndPoint=127.0.0.1:57213

Dropping into a shell I can see that at port in netstat.

TCP 127.0.0.1:57213 jenkins:0 LISTENING [dotCover.exe]

Looking for some direction on diagnosing this one.

3
6 comments

We have exactly the same problem with a new jenkins slave.

We have an old slave running fine since months, but the new slave always hangs at

Results (nunit3) saved as TestResult.xml

It doesn't make any difference if I use DotCover 2017.2 like on the old slave or upgrade to 2018.1.3.
Both slaves are running Windows10 LTSB 2016 (10.0.14393)

In the verbose log file I see the same line as @Jtsievert over an over again.

The strange thing is: If I call the exact same dotCover.exe command in the same location as the same user as Jenkins, but in a cmd.exe, it works just fine! It is stuck only for a few seconds and then finshes within some more seconds.

0

Hi,

Thank you for contacting us and sorry for the long silence.

Could you please provide us with more info:

0

This is what one of our problematic build slaves has installed:

>> Get-WmiObject -Class "win32_quickfixengineering"

Source Description HotFixID InstalledBy InstalledOn
------ ----------- -------- ----------- -----------
Update KB4049065 NT-AUTORITÄT\SYSTEM 14.03.2018 00:00:00
Update KB4054590 NT-AUTORITÄT\SYSTEM 21.06.2018 00:00:00
Update KB4089510 NT-AUTORITÄT\SYSTEM 09.04.2018 00:00:00
Update KB4093137 NT-AUTORITÄT\SYSTEM 09.05.2018 00:00:00
Update KB4132216 NT-AUTORITÄT\SYSTEM 01.06.2018 00:00:00
Security Update KB4343902 NT-AUTORITÄT\SYSTEM 30.08.2018 00:00:00
Security Update KB4343887 NT-AUTORITÄT\SYSTEM 30.08.2018 00:00:00

I'm not sure about the timing, but I believe that it worked until the April or May update and then stopped working.
After that our other slaves also stopped working one after another, without changing anything else, so it is most likely connected to one of these updates...

Our Jenkins slave runs under a normal user account without local admin rights.

We're not using Telerik JustMock. Instead we're using Moq.

Thanks for looking into it!

0

Hi Claudius,

Thank you for the information! Have you had time to try a registry-free dotCover configuration?

0

Okay, strange thing:

I activated coverage again for our build, tried the registry-free configuration and it worked. BUT: It now also worked again without the additional parameter, so the problem has vanished!
I just hope it's gone for good!

However this also means I can't help you any more in finding the original reason...

0

Great that it works fine for you now!
Thank you for the update, we'll keep the investigation.

0

Please sign in to leave a comment.