Stryker hangs for no reason ?

[candoumbe]

Describe the bug When running mutation tests for a github project, stryker hangs for no reason, making the github action run for more than 1 hour (for 357 mutants). I don't know if this could be related to #1317 , #27 or #1475. I came accross the issue when trying to run mutation tests for DataFilters. The repo contains several projects (which target multiple frameworks : netstandard1.3 , netstandard2.0, netstandard2.1 , net6.0 net7.0) and tests projects that targets net6.0 and net7.0.

Logs raw log.txt .

Expected behavior Mutation tests do not hang and run to completion.

Desktop (please complete the following information):

• OS: N/A
• Type of project [framework, core, xamarin]
• Framework Version sdk 7.0.400
• Stryker Version 3.10.0

Additional context For the context I set up a nightly-manual pipeline that only run mutation tests.

[dupdob]

thanks for reporting this issue. The log file you provided appears empty to me, can you double check it? Have you tried running Stryker locally on your machine ? The total test time depends on the total run time of the tests, test coverage and the number of generated mutants. I can easily surpass one hour for moderate size projects, so it does not count as being 'hang'.

[candoumbe]

Hello @dupdob

Here's logs.txt

Mutation tests taking time is something I do expect in my case. But it seems nothing going on (based on the logs I submitted) for several minutes 🤔

[rouke-broersma]

Do you have the progress reporter or the dots reporter turned on? If you don't, turn it on to see progress while running. It might simply be running without printing anything due to log level.

[candoumbe]

Do you have the progress reporter or the dots reporter turned on? If you don't, turn it on to see progress while running. It might simply be running without printing anything due to log level.

Will give a try and let you know what I found. Thanks for your help ;-)

[dupdob]

thanks for the log file @candoumbe . It looks like the testing phase never started. It looks a lot like an old bug that crept back: could you try setting a non null concurrency parameter (see here). It should be fixed, but this is easy to test. Did you run it on your machine ?

[richardwerkman]

@candoumbe have you tried the suggestion to set the concurrency? dotnet stryker -c 4 for example.

[candoumbe]

@dupdob , @richardwerkman Sorry for the late answer, I've been quite busy [in my other life 😅] The way the ci/cd works on the project where I encountered the issue made it impossible to set or change the concurrency parameter so I needed to work on that first. Now that I made that possible, I'll be able to run the ci/cd (probably within the next weekend) and will let you know what the outcome is.

[candoumbe]

So I ran the pipeline again and this time it ran to completion. Stryker was called using the following CLI

/home/runner/work/DataFilters/DataFilters//.nuke/temp/dotnet-unix/dotnet stryker --dashboard-api-key *** --reporter dashboard --reporter markdown --reporter html --target-framework net6.0 --output /home/runner/work/DataFilters/DataFilters/output/artifacts/tests-results/mutation-tests/DataFilters/net6.0 --project DataFilters.csproj --config-file /home/runner/work/DataFilters/DataFilters/test/DataFilters.UnitTests/stryker-config.json --test-project /home/runner/work/DataFilters/DataFilters/test/DataFilters.UnitTests/DataFilters.UnitTests.csproj --version 62a4aefb387446ac62c2450bfd549811c0106f7f --with-baseline:main

gives the following results.txt

The configuration files I used for mutation tests contains the following parameters :

{
  "stryker-config": {
    "project-info": {
      "module": <name of the module under test>
    },
    "concurrency": 4
  }
}

The full execution log can be found here

[dupdob]

thanks for the report. It confirms my initial suspicion that an old bug crept back: on some OSes, .Net fails getting the Core count and returns 0. ~And if you give a maximum of 0 concurrent task to Parallel.For, well, no task get executed at all. Stryker previously assumed at least one core, but I guess the safety has been lost in some refactoring. This should be easy to fix~ update: I don't believe this is the case anymore: an explicit warning is logged when Stryker gets 0 when asking for the number of cores. Plus, there as multiple safeties to use 1 as a min value. If you still have the issue, could you share the log file generated by the --log-to-file option?

[dupdob]

I will close this issue as it may be a transient and/or setup problem and there have been no update in 6 months. Feel free to reopen it with some update if this is still an issue for you