Bug 41701 - [regression] ManualResetEventSlim.Wait() malfunctions with longer wait period when run on async/threadpool
Summary: [regression] ManualResetEventSlim.Wait() malfunctions with longer wait period...
Status: RESOLVED DUPLICATE of bug 42688
Alias: None
Product: Runtime
Classification: Mono
Component: io-layer (show other bugs)
Version: unspecified
Hardware: PC Linux
: --- major
Target Milestone: (C7)
Assignee: Ludovic Henry
URL:
Depends on:
Blocks:
 
Reported: 2016-06-10 14:21 UTC by Łukasz Domeradzki
Modified: 2016-07-22 22:00 UTC (History)
6 users (show)

See Also:
Tags:
Is this bug a regression?: Yes
Last known good build: 4.2.3.4 / 4.3.2.467


Attachments
Reproducable test case (1.49 KB, text/plain)
2016-06-10 14:21 UTC, Łukasz Domeradzki
Details

Description Łukasz Domeradzki 2016-06-10 14:21:41 UTC
Created attachment 16276 [details]
Reproducable test case

Recently I noticed that I'm running into an awful issue in my code. It seems that waiting for longer period of time on a threadpool thread in async code leads to broken behaviour and cuts wait time to much shorter period.

Issue doesn't exist with latest Mono from Debian Testing branch - 4.2.1 version:


root@archi:~/tmp/MonoTest# mono --version
Mono JIT compiler version 4.2.1 (Debian 4.2.1.102+dfsg2-8)
Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com
        TLS:           __thread
        SIGSEGV:       altstack
        Notifications: epoll
        Architecture:  amd64
        Disabled:      none
        Misc:          softdebug
        LLVM:          supported, not enabled.
        GC:            sgen
root@archi:~/tmp/MonoTest# mono MonoTest/bin/Release/MonoTest.exe
We should sleep 5 seconds
And we slept for 5.015404 seconds
We should sleep 30 seconds
And we slept for 29.999703 seconds
We should sleep 900 seconds
And we slept for 900.019203 seconds


But it does exist with latest master (trunk) Mono from GitHub - currently 4.5.1 version:


root@archi:~/tmp/MonoTest# /opt/mono/bin/mono --version
Mono JIT compiler version 4.5.2 (master/ff4484f Fri 10 Jun 15:02:59 CEST 2016)
Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com
        TLS:           __thread
        SIGSEGV:       altstack
        Notifications: epoll
        Architecture:  amd64
        Disabled:      none
        Misc:          softdebug
        LLVM:          supported, not enabled.
        GC:            sgen
root@archi:~/tmp/MonoTest# /opt/mono/bin/mono MonoTest/bin/Release/MonoTest.exe
We should sleep 5 seconds
And we slept for 5.019781 seconds
We should sleep 30 seconds
And we slept for 29.999405 seconds
We should sleep 900 seconds
And we slept for 41.005449 seconds


I checked and affected Mono version sleeps properly with 60 seconds, but with 900 above malfunction is happening. Same issue is happening when code uses given amount of miliseconds (900000) instead of TimeSpan. It seems that issue can't be reproduced on main thread, but maybe it was just a coincidence.

I'm not entirely sure what might be the reason, it seems like some overflow (?) when used with values that are too high. I consider it a regression and I attached reproducable test case I used for above test. The affected Mono version is self-compiled one, but with default sort of flags, all supported options and only --prefix=/opt/mono specified. It's also up-to-date at the time of writing (compiled a few hours before this ticket). I'm using latest Debian Testing - GCC version (Debian 5.3.1-21) 5.3.1 20160528 + Mono 4.2.1 were used for compiling affected Mono version.

I'm not sure if there is anything else I could provide to help you locate the culprit - if there is anything, please let me know. I'd also be very grateful if you could prioritize this issue, as it's driving me crazy.

Thank you in advance. I really appreciate your effort.

Sincerely,
~Łukasz
Comment 1 Łukasz Domeradzki 2016-06-10 17:32:31 UTC
I did a few further tests to check out when exactly the regression happened, compiling from Mono tarballs (http://download.mono-project.com/sources/mono).

First broken version is 4.4.0.40.

Version 4.2.3.4 as well as 4.3.2.467 both work properly, so the regression happened somewhere between 4.3.2 <-> 4.4.0.
Comment 2 Łukasz Domeradzki 2016-06-10 19:06:01 UTC
Also actual sleep time seems to decrease the higher we go.

We should sleep 60 seconds
And we slept for 60.013241 seconds
We should sleep 2 seconds
And we slept for 2.011604 seconds
We should sleep 300 seconds
And we slept for 300.011472 seconds
We should sleep 600 seconds
And we slept for 170.506299 seconds
We should sleep 900 seconds
And we slept for 41.011244 seconds

Really strange...
Comment 3 Ludovic 2016-06-11 03:41:37 UTC
I have no idea why my email address was set as the assignee, I have never touched Xamarin code AFAIK :)   Anyway, I reset the assignee for the time being!
Comment 4 Marek Safar 2016-06-11 06:30:53 UTC
Ludovic@Chabant sorry I miss-assigned the bug
Comment 5 Łukasz Domeradzki 2016-06-25 20:58:36 UTC
Tested today, still reproducable as of Mono JIT compiler version 4.5.2 (master/737522f Sat 25 Jun 20:49:55 CEST 2016).
Comment 6 Łukasz Domeradzki 2016-07-21 17:28:56 UTC
This is fixed since https://github.com/mono/mono/commit/e62c5b001d767a390986591f6eec22c31cac136d - thanks!
Comment 7 Ludovic Henry 2016-07-22 22:00:51 UTC

*** This bug has been marked as a duplicate of bug 42688 ***

Note You need to log in before you can comment on or make changes to this bug.