[Mono-bugs] [Bug 537921] New: NullReferenceException in System.Timers.Timer.StartTimer()

[bugzilla_noreply at novell.com]

http://bugzilla.novell.com/show_bug.cgi?id=537921


           Summary: NullReferenceException in
                    System.Timers.Timer.StartTimer()
    Classification: Mono
           Product: Mono: Runtime
           Version: SVN
          Platform: x86-64
        OS/Version: Ubuntu
            Status: NEW
          Severity: Minor
          Priority: P5 - None
         Component: misc
        AssignedTo: mono-bugs at lists.ximian.com
        ReportedBy: teravus at gmail.com
         QAContact: mono-bugs at lists.ximian.com
          Found By: ---


User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET
CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022;
NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)

Stopping a Timer (Timer.Stop() in a thread while another thread starts a timer
(Timer.Start()) generates a NullReferenceException in Timers.cs

Exception: System.NullReferenceException: Object reference not set to an
instance of an object
  at System.Timers.Timer.StartTimer () [0x0005e] in
/usr/src/packages/BUILD/mono/mcs/class/System/System.Timers/Timer.cs:203 


Reproducible: Sometimes

Steps to Reproduce:
1. Create Two threads. One nonstatic timer.
2. In the first ThreadStart method, stop the timer in a for loop.
3. In the second ThreadStart method, start the timer in a for loop.
The easiest way to do this is to create two classes and assign the timer to a
property of both of them, but this can be triggered in any scenario where the
thread context is murky.
Actual Results:  
NullReferenceException

Expected Results:  
The Timer Should be stopped or started depending on what method was called
last.

According to the MSDN documentation, the only valid error to throw when someone
calls Timer.Start() is an System.ArgumentOutOfRangeException.   A
NullRefereneException here is completely invalid and points to a coding error
in the TimerStart() method in the Managed code.  Locking the Timer object with
the lock keyword, mitigates the issue by preventing the Stop from occurring
until the Start() is complete, but it's a workaround.   The same situation in
Microsoft .NET results in the Expected results listed above.

Additionally, the MSDN doesn't say anything about the thread safety of
Timer.Start().  It has the generic, 'instance properties are not gauranteed
thread safe' message..  so if you change the object reference a reader might
pick up a different reference to the object.  But, Microsoft .NET testing
doesn't generate a Null Reference exception or otherwise crash.   The timer may
not be in the state that the user intended in the code, but it doesn't crash.

I'm setting this to Minor, because there is an Easy work around, lock the
timer, however, I'm consistently getting patches from people who do NOT lock
their timers in code that can be accessed by multiple threads.   Additionally,
it isn't natural to assume that timers must be locked to call the Start()
method.  There are no blog, articles, or 'timer tutorials' that note that
Timers must be locked when being accessed by multiple threads.  Some even set
the timer Enabled property from within the Elapsed Event Handler.   The Null
Reference Exception is a common coding error when a reference type object is
referred to but the reference is null and it occurrs in Mono code.

-- 
Configure bugmail: http://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.