Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
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
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.
`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 `Terminal.app` command prompt:
On some attempts (at least on my system), the command fails with the following output:
> macuser$ /Library/Frameworks/Xamarin.Android.framework/Commands/mandroid --datafile
> 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
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.
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.
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.
sgen ignores GC_DONT_GC.
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-18.104.22.168.macos10.xamarin.x86_1f31596364233b78242321bd71d42c8967415d43
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: https://gist.github.com/Rajneesh360Logica/c180be2fe5293709ac7b
Full Environment: https://gist.github.com/Rajneesh360Logica/2a7355f33b2cbf8691bc
I have checked the same with XA mono-android-5.1.8-0 + MonoFramework-MDK-22.214.171.124.macos10.xamarin.x86_1f31596364233b78242321bd71d42c8967415d43 and observed that its working fine.
Observation: `mandroid --datafile` command give expected output
Screencast : http://www.screencast.com/t/FI6JgBPZ
Full environment Info: https://gist.github.com/Rajneesh360Logica/dd19e144dafcc61ebd56
As per bug milestone is C6 .I will verify this issue once the patch will merge in C6
As per comment 10, comment 11 and comment 12. this issue does not exist now.
Hence closing this issue by marking it as verified.