This is Xamarin's bug tracking system. For product support, please use the support links listed in your Xamarin Account.
Bug 35006 - `mandroid --datafile` command sometimes fails with "Stacktrace: at <unknown> <0xffffffff> at System.Text.Encoding.GetDataItem ()"
Summary: `mandroid --datafile` command sometimes fails with "Stacktrace: at <unknown> ...
Alias: None
Product: Android
Classification: Xamarin
Component: General (show other bugs)
Version: 5.1
Hardware: PC Mac OS
: Normal major
Target Milestone: 5.1.8 (Hotfix)
Assignee: Jonathan Pryor
Depends on:
Reported: 2015-10-16 23:51 UTC by Brendan Zagaeski
Modified: 2015-10-20 13:45 UTC (History)
7 users (show)

See Also:
Tags: BZRC5SR4S4_C5SR4S1
Is this bug a regression?: ---
Last known good build:


Description Brendan Zagaeski 2015-10-16 23:51:24 UTC
`mandroid --datafile` command sometimes fails with "Stacktrace: at <unknown> <0xffffffff> at System.Text.Encoding.GetDataItem ()"

## Regression status: seems to be a regression in XA 5.1.7 (Android M)

I can reproduce the problem on about 25-50% of attempts to run `mandroid --datafile` on XA 5.1.7, but 0% of the time on XA 5.1.6.

Note: I also haven't been able to reproduce the problem on Xamarin.Android 6.0 (Cycle 6 RC 0).

It seems the problem is sensitive to timing. Also, if I redirect standard error and standard output from `mandroid --datafile` on XA 5.1.7, I cannot hit the error. That said, there are several reports [1,2] from the field of customers hitting this during the _normal_ activation workflow, so it seems that my "slightly artifical" steps to reproduce are hitting a "real" problem.



## Steps to reproduce

Run the following command several times in succession in a `` command prompt:

/Library/Frameworks/Xamarin.Android.framework/Commands/mandroid --datafile

## Results

On some attempts (at least on my system), the command fails with the following output:

> macuser$ /Library/Frameworks/Xamarin.Android.framework/Commands/mandroid --datafile
> Stacktrace:
>   at <unknown> <0xffffffff>
>   at System.Text.Encoding.GetDataItem () <0x0001b>
>   at System.Text.Encoding.get_WebName () <0x0001b>
>   at System.Xml.XmlTextReaderImpl.SwitchEncoding (System.Text.Encoding) <0x00018>
>   at System.Xml.XmlTextReaderImpl.ParseXmlDeclaration (bool) <0x00477>
>   at System.Xml.XmlTextReaderImpl.Read () <0x000a3>
>   at System.Xml.XmlLoader.Load (System.Xml.XmlDocument,System.Xml.XmlReader,bool) <0x000ef>
>   at System.Xml.XmlDocument.Load (System.Xml.XmlReader) <0x0007b>
>   at System.Xml.XmlDocument.LoadXml (string) <0x00090>
>   at Xamarin.Licensing.PlatformActivation.TransformSystemProfilerOutput (string) <0x00036>
>   at Xamarin.Licensing.PlatformActivation.GetRegistrationXml (Mono.Touch.Activation.Common.License) <0x00163>
>   at Xamarin.Licensing.PlatformActivation.ShowDataFile () <0x00013>
>   at Xamarin.Licensing.PlatformActivation.ProcessOptions () <0x0010f>
>   at Monodroid.Arguments.Parse (System.Collections.Generic.IEnumerable`1<string>) <0x013af>
>   at Monodroid.MainClass.Main (string[]) <0x00023>
>   at (wrapper runtime-invoke) <Module>.runtime_invoke_int_object (object,intptr,intptr,intptr) <0xffffffff>
> Native stacktrace:
> Debug info from gdb:
> "monobt" command installed
> (lldb) command source -s 1 '/tmp/mono-gdb-commands.zA4IUj'
> (lldb) XR1LX.platform/Developer/SDKs/MacOSX10.10.sdk
> error: 'XR1L' is not a valid command.
> =================================================================
> Got a SIGSEGV while executing native code. This usually indicates
> a fatal error in the mono runtime or one of the native libraries 
> used by your application.
> =================================================================
> Abort trap: 6
Comment 2 Brendan Zagaeski 2015-10-17 00:39:28 UTC
Note that in "real world" activation failures caused by this problem, the stack trace will be prefaced by the generic "Could not load machine data" error.
Comment 3 Jérémie Laval 2015-10-17 10:37:39 UTC
It seems the cause of this issue is that the M release that went out was a compiled with a different environment on Wrench (in this case a 4.2 Mono instead of previously a 4.0 one).

This means that mandroid being mkbundled (thus embedding the current system Mono) is wrongly using cycle 6 code to run.
Comment 4 Jérémie Laval 2015-10-17 12:02:27 UTC
Cycle 6 RC0 and the M stable seemed to have been compiled with the same Mono version.

Activation differs slightly between the two build with notably one commit from Sébastien that touches that part of the code (activation/e68def859bbf690506017ee3e07cda2b94ec8ea2)

Additionally, the timing aspect of this problem being a usual suspect, I could notice that the command seems to work perfectly fine when passing the GC_DONT_GC environment variable (i.e. `GC_DONT_GC=true /Developer/MonoAndroid/usr/bin/mandroid --datafile`) which would seem to indicate this is a sgen bug.
Comment 5 Rodrigo Kumpera 2015-10-18 00:17:08 UTC
sgen ignores GC_DONT_GC.
Comment 10 Arpit Jha 2015-10-20 04:58:37 UTC
I have checked this issue and able to reproduce this issue with following build on OS X:10.11 machine with production server.

Mono C5 trunk : MonoFramework-MDK-
 Android  XA : mono-android-5.1.7-12_53fce3730830417896a42f365a5ba35f1ee58d9d
Cycle 5 Trunk:  mono-android-5.1.7-13_e30ab8527fe6ee17b9254d15cfa77a23c760e349

Note: However I am not able to reproduce this issue on OSX :10.10 .

Terminal output:
Full Environment:

I have checked the same with XA mono-android-5.1.8-0 +   MonoFramework-MDK- and observed that its working fine.

Observation: `mandroid --datafile` command give expected output

Screencast :
Terminal output:
Full environment Info:

As per bug milestone is C6 .I will verify this issue once the patch will merge in C6
Comment 13 Mohit Kheterpal 2015-10-20 13:45:57 UTC
As per comment 10, comment 11 and comment 12. this issue does not exist now.

Hence closing this issue by marking it as verified.

Note You need to log in before you can comment on or make changes to this bug.