[Mono-list] Seemingly impossible null reference exception running managed code with embedded Mono on Linux

[Jean-Michel.Perraud at csiro.au]

Ian, 
After a bit of homework on closures [1], I think I see what you mean. I don't think this is a modified closure issue: there is no access to a variable outside the scope of the lambda. I have used Array.ConvertAll with similar lambda functions many times. Also, Resharper does not complain as it would for an access to a modified closure so far as I know.

If anything I can only suspect an incorrect garbage collection on the variable 'Type[] types', unlikely as it is.

[1] http://sblakemore.com/blog/post/What-JavaScript-taught-me-about-C-%E2%80%93-Understanding-%E2%80%98Access-to-modified-closure%E2%80%99.aspx

-----Original Message-----
From: Ian Norton [mailto:ian.norton-badrul at thales-esecurity.com] 
Sent: Wednesday, 13 March 2013 1:50 AM
To: Perraud, Jean-Michel (CLW, Black Mountain)
Cc: mono-list at lists.ximian.com
Subject: Re: [Mono-list] Seemingly impossible null reference exception running managed code with embedded Mono on Linux

Could it be a modified closure thing?

On Tue, Mar 12, 2013 at 02:27:44AM +0000, Jean-Michel.Perraud at csiro.au wrote:
> Hi,
> 
> I am baffled by a couple of bugs I noticed running Mono (embedded in R) on a Linux box.
> 
> * Issues occur on a Debian64. Occurs with Mono 2.10.8 as well as when running on a recompiled mono using the 3.0.5 tag. 
> * Annoyingly, the issue disappears if I try to diagnose by attaching 
> to the MonoDevelop soft debugger
> * No issues running the same (c/c#) code with Mono 3.0.x on Windows.
> 
> I'd appreciate guru's insights/suggestions for methods to nail this fickle bug, which is a serious blocker for my purposes.
> 
> ==============================
> fuller repro information is at : http://r2clr.codeplex.com/workitem/47
> Scenario: R ==> Embedded Mono / c code ==> C# glue code
> 
> The call from the R interpreter:
>     clrGetStaticMembers(obj_or_typename='Rclr.ClrFacade')
> fails if called a third time in succession. There is no side effect that could explain why.
> Subsequent calls will all succeed. 
> 
> Key lines of code, where types == null seems *completely* impossible.
>     Type[] types = getTypes(arguments); // Array.ConvertAll(arguments, (x => (x == null ? typeof(object) : x.GetType())))
>     var method = classType.GetMethod(methodName, bindingFlags, null, 
> types, null);
> 
> Exception thrown in the method invocation Argument cannot be null.
> Parameter name: types
>   at System.Type.GetMethod (System.String name, BindingFlags 
> bindingAttr, System.Reflection.Binder binder, CallingConventions 
> callConvention, System.Type[] types, 
> System.Reflection.ParameterModifier[] modifiers) [0x00000] in 
> <filename unknown>:0
> 
> 
> _______________________________________________
> Mono-list maillist  -  Mono-list at lists.ximian.com 
> http://lists.ximian.com/mailman/listinfo/mono-list