counts.MaxWorking > 0 (src/vm/win32threadpool.h Line: 202) assertion failure

[ruben-ayrapetyan]

Hello.

There is a failure when running binary-trees benchmark (details below):

Assert failure(PID 3929 [0x00000f59], Thread: 3935 [0x0f5f]): counts.MaxWorking > 0
    File: /opt/coreclr/.../src/vm/win32threadpool.h Line: 202
    Image: /home/.../test/dotnet.master/corerun

Aborted

Architecture: armel

Build type: Debug

Hardware: Odroid-XU4

Commit hash: 48c1ec9

CoreFX: https://ci.dot.net/job/dotnet_corefx/job/master/job/tizen_armel_cross_release/2952/artifact/bin/build.tar.gz (seems to be a989d4f)

Command line: CLR_ICU_VERSION_OVERRIDE=57.1 ./corerun -c . ../bin-trees.dll 16

Test: bin-trees.dll.zip - a slightly modified version of a binary-trees benchmark from benchmarksgame.alioth.debian.org

CC @jkotas @janvorli @Dmitri-Botcharnikov @gbalykov @kvochko

[jkotas]

cc @kouvel

[ruben-ayrapetyan]

The failure does also occur on 0a17ae1, which is built locally:

sudo ./cross/build-rootfs.sh armel tizen lldb3.6
./build.sh armel debug clang3.9 skipgenerateversion skiptests skipnuget verbose cross -rebuild -cmakeargs -DFEATURE_GDBJIT=TRUE

Build system: Ubuntu 17.04
dotnet cli: dotnet-dev-linux-x64.2.0.0-preview1-005977
Can the build on unsupported ubuntu.17.04-x64 lead to this failure?

The build repository is just cloned, with following change:

diff --git a/build.sh b/build.sh
index 7fc2cb110..aeb81c61d 100755
--- a/build.sh
+++ b/build.sh
@@ -400,7 +400,7 @@ isMSBuildOnNETCoreSupported()
         if [ "$__HostOS" == "Linux" ]; then
             __isMSBuildOnNETCoreSupported=1
             # note: the RIDs below can use globbing patterns
-            UNSUPPORTED_RIDS=("debian.9-x64" "ubuntu.17.04-x64")
+            UNSUPPORTED_RIDS=("debian.9-x64")
             for UNSUPPORTED_RID in "${UNSUPPORTED_RIDS[@]}"
             do
                 if [[ $__HostDistroRid == $UNSUPPORTED_RID ]]; then

However, the failure doesn't occur with binaries, which are downloaded from: https://ci.dot.net/job/dotnet_coreclr/job/master/job/armel_cross_debug_tizen/1827 (0a17ae1)

If I use System.Private.CoreLib.dll from the archive and other parts built locally, the failure still occurs.

[kouvel]

@ruben-ayrapetyan, if you're able to repro this consistently, could you please get a stack trace and also check the value of MaxWorking at the time of failure (assuming it's 0). How many cores does the machine have?

[kouvel]

Also what's the value of ThreadpoolMgr::MinLimitTotalWorkerThreads? The only way I can see this happening is if MinLimitTotalWorkerThreads is set to 0 through Thread.SetMinThreads, which probably shouldn't be allowed anyway but I don't see any calls to it in the IL. Wondering if some binaries may be out of sync, could you also put a breakpoint in ThreadpoolMgr::SetMinThreads to make sure that is not the case?

[kouvel]

Closing with fix above assuming that is what was happening