This resolves bug # 18398 (https://bugzilla.xamarin.com/show_bug.cgi?id=18398) and other OOM scenarios in long running applications that make use of FromAsync, ContinueWith, etc. to "rearm" asynchronous operations.

While investigating an OOM scenario in my server application that uses SignalR and Katana/OWIN I came to discover that Mono was leaking memory with Task constructs such as FromAsync and ContinueWith. Further analysis (you can read the full details in the bugzilla thread) showed that the leak only happened when a new Task was created from within the thread of execution of another task.

The root cause of the leak stems from the use of the parent field in Task. Whenever as part of a Task handler you fire off a new task, the current task becomes the parent of the new task. This parent reference in the new task prevents the GC from being able to collect the old finished task. This gets real bad in typical server code, where you asynchronously handle stuff and then FromAsync or whatever to setup subsequent requests. What you end up with is an infinitely descending chain of Task objects, and eventually you run out of memory and crash.

The fix is simple. When the Task is finished (or Dispose'd), set the parent to null to break the reference. The GC can then do it's job. In my test app that was leaking like crazy, memory utilization is now rock solid.

** This is a revised attempt (2nd try). The previous attempt caused a regression failure of the WaitChildWithNesting test because it pretty much broke TaskCreationOptions.AttachedToParent.

If there is anything else I need to do in order for this PR to be accepted, I'm ready and willing. It would totally make my day to get a commit into Mono!

Your test should follow the Mono Coding Guidelines, i.e. space before an opening parenthesis and no "m_" prefixes.

For the record as the changeset is not showing up here, this was merged with: cde40fa...a10df86

Got it. Thanks @marek-safar for reviewing and editing. I'm glad to finally have this fixed in master.