Bug 42615 - TaskExceptionHolder.AddFaultException throws NullReferenceException and ArgumentException unexpectedly
Summary: TaskExceptionHolder.AddFaultException throws NullReferenceException and Argum...
Alias: None
Product: Class Libraries
Classification: Mono
Component: mscorlib ()
Version: 4.4.0 (C7)
Hardware: PC Windows
: Normal normal
Target Milestone: Future Release
Assignee: João Matos
Depends on:
Reported: 2016-07-17 09:55 UTC by Jahmai
Modified: 2018-03-13 11:07 UTC (History)
4 users (show)

Is this bug a regression?: ---
Last known good build:

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:

Description Jahmai 2016-07-17 09:55:48 UTC
I don't have a reproduction for this yet, but I'm observing the following crashes in the wild and think it deserves a bug report:

Crash #1:

Caused by xamarin.android.crashlytics.MonoException: (NullReferenceException) Object reference not set to an instance of an object
at System.Threading.Tasks.TaskExceptionHolder.AddFaultException(System.Object exceptionObject)<0xda9ad680 + 0x002fc>(TaskExceptionHolder0xda9ad6800x002fc.cs:1)
at System.Threading.Tasks.TaskExceptionHolder.Add(System.Object exceptionObject, Boolean representsCancellation)<0xda9ad220 + 0x0003b>(TaskExceptionHolder0xda9ad2200x0003b.cs:1)
at System.Threading.Tasks.Task.AddException(System.Object exceptionObject, Boolean representsCancellation)<0xda9aa950 + 0x0010b>(Task0xda9aa9500x0010b.cs:1)
at System.Threading.Tasks.Task.AddException(System.Object exceptionObject)<0xda9a9a60 + 0x0001f>(Task0xda9a9a600x0001f.cs:1)
at System.Threading.Tasks.Task`1TResult.TrySetException(System.Object exceptionObject)<0xda9a75f0 + 0x00047>(Task1TResult0xda9a75f00x00047.cs:1)
at System.Threading.Tasks.TaskCompletionSource`1TResult.TrySetException(System.Exception exception)<0xda9a7338 + 0x0005b>(TaskCompletionSource1TResult0xda9a73380x0005b.cs:1)
at System.Threading.Tasks.TaskCompletionSource`1TResult.SetException(System.Exception exception)<0xda9556f0 + 0x00027>(TaskCompletionSource1TResult0xda9556f00x00027.cs:1)
at Intrinsic.Threading.Tasks.TaskCompletionSource.SetException(System.Exception exception)<0xda955698 + 0x00027>(TaskCompletionSource0xda9556980x00027.cs:1)
at Intrinsic.Threading.Tasks.AsyncManualResetEvent.CreateDisposedSource()<0xda955438 + 0x00093>(AsyncManualResetEvent0xda9554380x00093.cs:1)
at Intrinsic.Threading.Tasks.AsyncManualResetEvent..cctor()<0xda9553e8 + 0x00007>(0xda9553e80x00007.cs:1)

Crash #2:

D/Crashlytics System.ArgumentException: (Internal)Expected an Exception or an IEnumerable<Exception> Parameter name: exceptionObject at
 System.Threading.Tasks.TaskExceptionHolder.AddFaultException (System.Object exceptionObject) <0xdb5a9c20 + 0x002dc> in <filename unknown>:0 at
 System.Threading.Tasks.TaskExceptionHolder.AddFaultException (System.Object exceptionObject) <0xdb5a9778 + 0x002f7> in <filename unknown>:0 at
 System.Threading.Tasks.TaskExceptionHolder.Add (System.Object exceptionObject, Boolean representsCancellat
ion) <0xdb5a90b8 + 0x0003b> in <filename unknown>:0 at
 System.Threading.Tasks.Task.AddException (System.Object exceptionObject, Boolean representsCancellat
ion) <0xdbf137d0 + 0x0010b> in <filename unknown>:0 at
 System.Threading.Tasks.Task.AddException (System.Object exceptionObject) <0xdbf13670 + 0x0001f> in <filename unknown>:0 at
 System.Threading.Tasks.Task`1TResult.TrySetException (System.Object exceptionObject) <0xdbf120f8 + 0x00047> in <filename unknown>:0 at
 System.Threading.Tasks.TaskCompletionSource`1TResult.TrySetException (System.Exception exception) <0xdbf11e78 + 0x0005b> in <filename unknown>:0 at
 Intrinsic.Threading.Tasks.TaskCompletionSource.TrySetException (System.Exception exception) <0xdbf11de0 + 0x00027> in <filename unknown>:0 at
 Intrinsic.Net.Sockets.SocketExtensions.Complete (System.Net.Sockets.SocketAsyncEventArgs e) <0xdbf103c8 + 0x00117> in <filename unknown>:0 at
 Intrinsic.Net.Sockets.SocketExtensions.OnCompleted (System.Object sender, System.Net.Sockets.SocketAsyncEventArgs e) <0xdbf10150 + 0x00017> in <filename unknown>:0 at
 System.Net.Sockets.SocketAsyncEventArgs.OnCompleted (System.Net.Sockets.SocketAsyncEventArgs e) <0xdbf10108 + 0x0003b> in <filename unknown>:0 at
 System.Net.Sockets.SocketAsyncEventArgs.Complete () <0xdbf100b8 + 0x0001f> in <filename unknown>:0 at
 System.Net.Sockets.Socket.<SendToAsyncCallback>m_E (IAsyncResult ares) <0xdbf0dd88 + 0x001a7> in <filename unknown>:0 at
 System.Net.Sockets.SocketAsyncResult+<Complete>cAnonStorey0.<>m_0 (System.Object _) <0xdbf0dd50 + 0x0002b> in <filename unknown>:0 at
 System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem () <0xdbf0db58 + 0x0002f> in <filename unknown>:0 at
ch () <0xeebc84c0 + 0x001db> in <filename unknown>:0 at
 System.Threading._ThreadPoolWaitCallback.PerformWaitCallback () <0xeebc82f0 + 0x00007> in <filename unknown>:0

I've read the source and I can't see how a null parameter can be passed through each of the call chains without resulting in an ArgumentNullException as early as TaskCompletionSource.TrySetException so I'm fairly confident it's not our usage that is the problem.
Comment 1 Rodrigo Kumpera 2016-07-20 01:03:03 UTC
What version of Xamarin Android are you running on?

We recently fixed an issue that could potentially trigger this, though I can't say whether this is affected or not.

Ludovic, which Android version shipped the GC register scanning bug?
Comment 2 Jahmai 2016-07-20 01:42:13 UTC
This issue is seen on releases running on Xamarin Android 6.1.

I think you're referring to https://bugzilla.xamarin.com/show_bug.cgi?id=38012

Actually we've seen a few issues resolved as a result of 38012 but this issue I've reported today is only from recent releases.

The weirdest thing is Crash #1 happens at application bootstrap inside a class constructor, so it should really be impossible for a garbage collection to happen.

It almost reads more like memory corruption, but impossible to tell.

I've tried reproducing it in a project but failed to do so, but will keep trying.
Comment 3 Rodrigo Kumpera 2016-07-20 02:56:40 UTC

There is one thing you could look for when it comes to those bizarre Android issues.

We had multiple device specific issues over the years and this might be one of those. So, if your crash analytics tool allows for, check if there are specific phone + os combinations that stand out.

If there's one, we can try to come up with a stress test on XTC.
Comment 4 Jahmai 2016-07-20 03:42:04 UTC
Ok I'll take a look at the device stats and see if there it's a consistent device family. Thanks for the tip!
Comment 5 Jahmai 2016-07-25 11:49:53 UTC
All recent reproductions of this issue are on an SM-G935F (Samsung Galaxy 7 Edge).
Comment 6 Rodrigo Kumpera 2016-07-25 15:25:31 UTC
Hey João,

The affected device here is the same you're tracking an issue already, right?
Comment 7 Jahmai 2016-10-18 00:37:28 UTC
I've raised another "meta issue" for this: https://bugzilla.xamarin.com/show_bug.cgi?id=45530
Comment 8 Marek Safar 2018-03-13 11:07:20 UTC
We have not received the requested information. If you are still experiencing this issue please provide all the requested information and reopen the bug report.

Thank you!