Bug 3676 - NullReferenceException at Array.Copy in ClientRuntimeChannel Debug simulator
Summary: NullReferenceException at Array.Copy in ClientRuntimeChannel Debug simulator
Alias: None
Product: iOS
Classification: Xamarin
Component: Debugger ()
Version: 5.0
Hardware: Macintosh Mac OS
: --- normal
Target Milestone: Untriaged
Assignee: Bugzilla
: 1529 5320 5334 ()
Depends on:
Reported: 2012-02-28 19:48 UTC by Brian Lanham
Modified: 2013-03-15 00:54 UTC (History)
8 users (show)

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

fix.patch (1.60 KB, patch)
2012-03-28 11:12 UTC, Rolf Bjarne Kvinge [MSFT]

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 Developer Community or GitHub 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 Brian Lanham 2012-02-28 19:48:02 UTC
This started happening very recently.  The only change I have made is upgrading to 8GB of RAM.  I am connecting to WCF-based hosted services using proxy classes generated with the slsvcutil.exe utility.  I have been doing this for over a year successfully and this condition started within the last week.  

This condition ONLY occurs in Debug mode with the simulator.  I have NOT tried it connected to a device in debug mode.  When I run in "Release" mode the app runs but, of course, I can't debug.  Any help you can provide is appreciated.

Here is the stack trace:

  at System.Array.Copy (System.Array sourceArray, Int32 sourceIndex, System.Array destinationArray, Int32 destinationIndex, Int32 length) [0x00104] in /Developer/MonoTouch/Source/mono/mcs/class/corlib/System/Array.cs:979 
  at System.Collections.ArrayList.CopyTo (Int32 index, System.Array array, Int32 arrayIndex, Int32 count) [0x0002d] in /Developer/MonoTouch/Source/mono/mcs/class/corlib/System.Collections/ArrayList.cs:3064 
  at System.Collections.ArrayList.CopyTo (System.Array array, Int32 arrayIndex) [0x00000] in /Developer/MonoTouch/Source/mono/mcs/class/corlib/System.Collections/ArrayList.cs:3046 
  at System.MonoCustomAttrs.GetCustomAttributes (ICustomAttributeProvider obj, System.Type attributeType, Boolean inherit) [0x0026c] in /Developer/MonoTouch/Source/mono/mcs/class/corlib/System/MonoCustomAttrs.cs:259 
  at System.Reflection.MonoMethod.GetCustomAttributes (System.Type attributeType, Boolean inherit) [0x00000] in /Developer/MonoTouch/Source/mono/mcs/class/corlib/System.Reflection/MonoMethod.cs:291 
  at System.Runtime.Serialization.SerializationMap..ctor (System.Type type, System.Xml.XmlQualifiedName qname, System.Runtime.Serialization.KnownTypeCollection knownTypes) [0x0006d] in /Developer/MonoTouch/Source/mono/mcs/class/System.Runtime.Serialization/System.Runtime.Serialization/SerializationMap.cs:111 
  at System.Runtime.Serialization.SharedContractMap..ctor (System.Type type, System.Xml.XmlQualifiedName qname, System.Runtime.Serialization.KnownTypeCollection knownTypes) [0x00000] in <filename unknown>:0 
  at System.Runtime.Serialization.KnownTypeCollection.RegisterContract (System.Type type) [0x00039] in /Developer/MonoTouch/Source/mono/mcs/class/System.Runtime.Serialization/System.Runtime.Serialization/KnownTypeCollection.cs:917 
  at System.Runtime.Serialization.KnownTypeCollection.DoTryRegister (System.Type type) [0x00046] in /Developer/MonoTouch/Source/mono/mcs/class/System.Runtime.Serialization/System.Runtime.Serialization/KnownTypeCollection.cs:745 
  at System.Runtime.Serialization.KnownTypeCollection.TryRegister (System.Type type) [0x0000c] in /Developer/MonoTouch/Source/mono/mcs/class/System.Runtime.Serialization/System.Runtime.Serialization/KnownTypeCollection.cs:723 
  at System.Runtime.Serialization.KnownTypeCollection.InsertItem (Int32 index, System.Type type) [0x00019] in /Developer/MonoTouch/Source/mono/mcs/class/System.Runtime.Serialization/System.Runtime.Serialization/KnownTypeCollection.cs:466 
  at System.Collections.ObjectModel.Collection`1[System.Type].Add (System.Type item) [0x0000c] in /Developer/MonoTouch/Source/mono/mcs/class/corlib/System.Collections.ObjectModel/Collection.cs:74 
  at System.Runtime.Serialization.DataContractSerializer.RegisterTypeAsKnown (System.Type type) [0x00026] in /Developer/MonoTouch/Source/mono/mcs/class/System.Runtime.Serialization/System.Runtime.Serialization/DataContractSerializer.cs:238 
  at System.Runtime.Serialization.DataContractSerializer.PopulateTypes (IEnumerable`1 knownTypes) [0x00058] in /Developer/MonoTouch/Source/mono/mcs/class/System.Runtime.Serialization/System.Runtime.Serialization/DataContractSerializer.cs:226 
  at System.Runtime.Serialization.DataContractSerializer..ctor (System.Type type, System.String rootName, System.String rootNamespace, IEnumerable`1 knownTypes) [0x0004b] in /Developer/MonoTouch/Source/mono/mcs/class/System.Runtime.Serialization/System.Runtime.Serialization/DataContractSerializer.cs:107 
  at System.ServiceModel.Dispatcher.DataContractMessagesFormatter.GetSerializer (System.ServiceModel.Description.MessagePartDescription partDesc) [0x00011] in /Developer/MonoTouch/Source/mono/mcs/class/System.ServiceModel/System.ServiceModel.Dispatcher/BaseMessagesFormatter.cs:447 
  at System.ServiceModel.Dispatcher.DataContractMessagesFormatter.ReadMessagePart (System.ServiceModel.Description.MessagePartDescription part, System.Xml.XmlDictionaryReader r) [0x00032] in /Developer/MonoTouch/Source/mono/mcs/class/System.ServiceModel/System.ServiceModel.Dispatcher/BaseMessagesFormatter.cs:435 
  at System.ServiceModel.Dispatcher.DataContractMessagesFormatter.MessageToParts (System.ServiceModel.Description.MessageDescription md, System.ServiceModel.Channels.Message message) [0x000b8] in /Developer/MonoTouch/Source/mono/mcs/class/System.ServiceModel/System.ServiceModel.Dispatcher/BaseMessagesFormatter.cs:414 
  at System.ServiceModel.Dispatcher.BaseMessagesFormatter.DeserializeReply (System.ServiceModel.Channels.Message message, System.Object[] parameters) [0x0004d] in /Developer/MonoTouch/Source/mono/mcs/class/System.ServiceModel/System.ServiceModel.Dispatcher/BaseMessagesFormatter.cs:273 
  at System.ServiceModel.Dispatcher.OperationFormatter.DeserializeReply (System.ServiceModel.Channels.Message message, System.Object[] parameters) [0x00000] in /Developer/MonoTouch/Source/mono/mcs/class/System.ServiceModel/System.ServiceModel.Dispatcher/BaseMessagesFormatter.cs:90 
  at System.ServiceModel.MonoInternal.ClientRuntimeChannel.Request (System.ServiceModel.Description.OperationDescription od, System.Object[] parameters) [0x001cb] in /Developer/MonoTouch/Source/mono/mcs/class/System.ServiceModel/System.ServiceModel/ClientRuntimeChannel.cs:556 
  at System.ServiceModel.MonoInternal.ClientRuntimeChannel.DoProcess (System.Reflection.MethodBase method, System.String operationName, System.Object[] parameters) [0x00038] in /Developer/MonoTouch/Source/mono/mcs/class/System.ServiceModel/System.ServiceModel/ClientRuntimeChannel.cs:486 
  at System.ServiceModel.MonoInternal.ClientRuntimeChannel.Process (System.Reflection.MethodBase method, System.String operationName, System.Object[] parameters) [0x00000] in /Developer/MonoTouch/Source/mono/mcs/class/System.ServiceModel/System.ServiceModel/ClientRuntimeChannel.cs:466
Comment 1 Rolf Bjarne Kvinge [MSFT] 2012-02-29 04:16:00 UTC
I've seen this before, every once in a while, but I have not been able to figure out what was causing it.

Does it happen every time you debug?
What happens if you just continue, will the app exit?
Do you get the same exception if you create a new project and connect to the same service?
Do you get the same exception if you try to use a different service?

If you also could try to provide a test case I can use to reproduce this issue, it would be a lot easier to track down.
Comment 2 Brian Lanham 2012-02-29 15:55:05 UTC
It is my belief that the debug libs are somehow corrupted but I can't be certain.

* It does happen every time I debug.
* No, the app just doesn't display any data.
* I created a new project with a tableview and tried loading it. Same error.
* Yes. I have a different project connecting to a different service and get the same error on that project.

Not sure what you mean by test case.  Do you want a service to connect to?
Comment 3 Rolf Bjarne Kvinge [MSFT] 2012-02-29 18:55:17 UTC
A test case would be a small project I can use to reproduce the issue, if possible with a service too (you can add private attachments here only Xamarin employees will see, by ticking the "Make attachment and comment private" checkbox when you upload).

Also, which version of MonoTouch are you using?
Comment 5 Brian Lanham 2012-03-01 09:04:08 UTC
I attached a "clean" project I created yesterday per your suggestion.  In the code is the URL for the service I am using.  I am using MonoDevelop with MonoTouch 5.0 (working on upgrading).
Comment 6 Rolf Bjarne Kvinge [MSFT] 2012-03-02 07:23:46 UTC
Thanks Brian, I can reproduce this now (interestingly enough only every second time I run it).

Zoltan: can you have a look at this? At first sight this looks like a jit bug of some sort when the debugger is attached. A NRE is thrown at this line (Array.cs:979):

Type dst_type = destinationArray.GetType ().GetElementType ();

but destinationArray is not null (it's been used previously in the same method and not assigned to, and the debugger also confirms it). There aren't any nearby lines which can throw NREs either.
Comment 7 Zoltan Varga 2012-03-02 16:18:07 UTC
It is definitely a runtime problem. Its pretty random, it happens about 1 times in 10 for me.
Comment 8 Brian Lanham 2012-03-07 18:56:24 UTC
It happens for me every time.  I am getting by in Release mode.  Thank you for looking into this.  I'm glad you were able to reproduce it.  What do I need to do now, if anything, to this ticket?
Comment 9 Nic Wise 2012-03-10 11:13:55 UTC
I'm getting this with the NewtonSoft json lib's. But only if I do it within a Thread (Task-based, if that helps). If it's in the main thread, no problem.

here's the start of the thread with stack dumps etc:

Comment 10 Brian Lanham 2012-03-14 08:57:11 UTC
I have confirmed that I can avoid this error by not sending multiple threads off.  I did successfully fire an async call and now it is running in debug mode.  I will queue my async calls (a better practice I am using in other apps anyway) to avoid this problem in debug.  Thanks for digging into it and letting me know what you found.  I look forward to any updates.

Do I mark it "resolved" because the cause is discovered and a work around is available?  I'm new to this protocol.
Comment 11 Zoltan Varga 2012-03-14 10:57:36 UTC
Its not resolved, this is still a bug.
Comment 12 Rolf Bjarne Kvinge [MSFT] 2012-03-16 09:54:21 UTC
I was able to reproduce the NRE on MonoTouch 5.0.4 (it took a lot more tries though) using the test project in comment 4.

It is very random now though (with master), it can crash 3 times in a row then run 30 times perfectly fine :|

On a sidenote it's not related to having the debugger attached, it also happens when just executing normally without attaching the debugger - but it's not noticed since the exception is swallowed.
Comment 13 Rolf Bjarne Kvinge [MSFT] 2012-03-16 10:29:55 UTC
It seems to be related to multiple threads running the same code.

If I change the sample in comment 4 to start 10 requests at startup instead of 2, it seems to be easier to reproduce, and I even can sometimes get 9 threads to throw the NRE (but never all 10 of them).

Another thing is that if the NRE is thrown, it's always in the first "wave" of requests, never after.

Zoltan: could it be that obj.GetType isn't thread-safe in some strange scenario?
Comment 15 Zoltan Varga 2012-03-17 19:49:04 UTC
Its very hard to reproduce this, I got it once out of maybe 50 tries.
Comment 16 Zoltan Varga 2012-03-25 12:52:18 UTC
What configuration/options are you using to reproduce this ?
Comment 17 Nic Wise 2012-03-26 05:06:51 UTC
If it's any help, I was using NewtonSoft JSON.NET from a thread. Works fine from the UI thread, but not from a Task-based thread.
Comment 18 Zoltan Varga 2012-03-28 07:34:24 UTC
Nic: could you create a testcase to help us reproduce the issue ?
Comment 20 Zoltan Varga 2012-03-28 08:42:29 UTC
rolf: I can't repro with that testcase either. I tried debugging the app, simply running it, running it from the command line a loop, nothing seems to work.
Comment 21 Rolf Bjarne Kvinge [MSFT] 2012-03-28 09:32:24 UTC
Zoltan: I guess that means I'll have to track this one down too :)
Comment 22 Zoltan Varga 2012-03-28 10:03:20 UTC
You could try reducing the testcase into something which just calls getcustomattributes or something
Comment 23 Rolf Bjarne Kvinge [MSFT] 2012-03-28 11:12:23 UTC
Created attachment 1588 [details]

The attached patch seems to fix the issue for me.

The problem is that when creating MonoVTables we assign 'type' after releasing the locks.
Comment 24 Zoltan Varga 2012-03-28 13:16:35 UTC
Good catch. I didn't even bother looking at that code, since I couldn't image that such core code would have a race. It looks like it does.
Comment 25 Zoltan Varga 2012-03-29 03:09:31 UTC
Should be fixed in master/2.10/mobile-master. Hopefully it won't break anything.
Comment 26 Sebastien Pouliot 2012-04-09 18:36:10 UTC
*** Bug 1529 has been marked as a duplicate of this bug. ***
Comment 27 Travis Bolinger 2012-05-25 18:39:28 UTC
*** Bug 5334 has been marked as a duplicate of this bug. ***
Comment 28 Rolf Bjarne Kvinge [MSFT] 2012-07-16 18:29:09 UTC
*** Bug 5320 has been marked as a duplicate of this bug. ***
Comment 29 curylod 2013-03-15 00:37:33 UTC
Looking at https://github.com/mono/mono/blob/master/mono/metadata/object.c it doesn't appear that the patch mentioned here is included in the latest mono source.  Is it and I'm just not seeing it?
Comment 30 Zoltan Varga 2013-03-15 00:54:11 UTC
The patch is there, it was added as 557356ee88aab557b27251192d79a057e891d5af.