[Mono-bugs] [Bug 648130] New: Calling Timer.Change(Infinite, Infinite) leaks timer objects on the scheduler

bugzilla_noreply at novell.com bugzilla_noreply at novell.com
Wed Oct 20 16:33:54 EDT 2010


https://bugzilla.novell.com/show_bug.cgi?id=648130

https://bugzilla.novell.com/show_bug.cgi?id=648130#c0


           Summary: Calling Timer.Change(Infinite, Infinite) leaks timer
                    objects on the scheduler
    Classification: Mono
           Product: Mono: Class Libraries
           Version: 2.6.x
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: Major
          Priority: P5 - None
         Component: CORLIB
        AssignedTo: mono-bugs at lists.ximian.com
        ReportedBy: bassam at symform.com
         QAContact: mono-bugs at lists.ximian.com
          Found By: ---
           Blocker: ---


User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.10)
Gecko/20100914 Firefox/3.6.10 ( .NET CLR 3.5.30729; .NET4.0E)

We are seeing an issue where timers stop firing. We have a consistent repro for
this, but we've been struggling with getting an isolated repro. We've narrowed
it down to the change made to the TimerComparer (as a result of the fix for
605092) where reference equality is used as a tie breaker when next_run values
are equal.

Here is what we see:

1) Two timers objects (A and B) are created with exactly the same due time
(happens quite frequently in our system)
2) A is added to the list maintained by the Scheduler.
3) When B is added the code in Scheduler.Add checks if there is already a entry
with the same next_run value (list.IndexOfKey). The TimerComparer finds such an
entry and uses reference equality between A and B, and since they are not equal
returns -1. This causes IndexOfKey fail to find the object. As a result, the
code to handle collisions in Scheduler.Add is never invoked and now have A and
B on the scheduler list with the same next_run value.
4) ChangeTime(-1,-1) is called on B, which sets next_run to ulong.MaxValue but
does NOT remove it from the list, again because the TimerComparer finds A.
5) From this point onwards the sorted list is corrupt (i.e. not sorted). All
comparison are pretty random at this point.

At this state we see lots of timer objects in the sorted list with next_run =
ulong.MaxValue, and our valid timer objects do not fire.

If this description is not enough to help you fix this issue, we can continue
working on an isolated fix. Alternatively we can give you access to debug one
of our machines if you'd like.




Reproducible: Sometimes

-- 
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.


More information about the mono-bugs mailing list