I'm trying to use mono-symbolicate to symbolicate stack traces produced by the release version of our app. In the .csproj Release build settings DebugSymbols, Optimize, MonoSymbolArchive have all been set to True, and DebugType has been set to Full.
When building Release, it seems to successfully generate the msym folder MyApp.Droid 7-13-18 3.35 PM.apkarchive/mSYM/com.myco.myapp.apk.mSYM which contains many GUID-named folders, some containing a single .msym file and some containing both a .dll and .pdb file. As I can see in my stack trace, it seems my MyApp.Droid has been given the GUID 7216aaa9c1294991b8b2782974cfb879 and looking in the directory of the same name, I do indeed see MyApp.Droid.dll and MyApp.Droid.pdb. Browsing through the msym folder, I also find four other directories each containing a file called MyApp.Droid.msym, which I assume means it splits the msym up into several files for some reason.
Using the minimal stack trace
at MyApp.Droid.MainActivity.OnCreate (Android.OS.Bundle savedInstanceState) <0x7c92255fd8 + 0x0008b> in <bf44972100fb4c2b8f5abcae2e982c3f>:0
(or any more complete, longer stack trace for that matter) and running mono-symbolicate path/to/MyApp.Droid 7-13-18 3.35 PM.apkarchive/mSYM/com.myco.myapp.apk.mSYM myStackTrace.txt, the mono-symbolicate script crashes with the following error:
System.IndexOutOfRangeException: Index was outside the bounds of the array.
at Mono.SymbolManager.GetOrCreateSeqPointInfo (System.String aotid) [0x00057] in <e1e81dae0fc04bc2a59e1766bbba201f>:0
at Mono.SymbolManager.TryResolveLocation (Mono.StackFrameData sfData) [0x0002e] in <e1e81dae0fc04bc2a59e1766bbba201f>:0
at Mono.Symbolicate.SymbolicateAction (System.Collections.Generic.List`1[T] args) [0x00034] in <e1e81dae0fc04bc2a59e1766bbba201f>:0
at Mono.Symbolicate.Main (System.String[] args) [0x0017f] in <e1e81dae0fc04bc2a59e1766bbba201f>:0
Reading the source code of mono-symbolicate, it seems like it's failing due to trying to parse an aotid from the stack trace, which it does not seem to contain. My understanding is that this aotid would be a second part inside the last angular brackets, such as:
at MyApp.Droid.MainActivity.OnCreate (Android.OS.Bundle savedInstanceState) <0x7c92255fd8 + 0x0008b> in <bf44972100fb4c2b8f5abcae2e982c3f#4ed70d01848e11d51d01dac0cb2d805e>:0
where 4ed70d01848e11d51d01dac0cb2d805e matches one of the folder names which include an MyApp.Droid.dll.msym file. Indeed, manually finding the folders which contain a MyApp.Droid.dll.msym and adding #foldername as a suffix in the angular brackets, I find one that works (does not produce a crash) after a few tries.
Why am I not getting the AOTIDs in the stacktrace, or how can I work around this?
