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)

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


Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.


Please create a new report on GitHub or Developer Community with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:
Status:
RESOLVED DUPLICATE of bug 42688

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 ***