Not seeing my application's code lines in HockeyApp stack traces

[justintoth]

I updated the paths in the App.Config:

<add key="archivePath" value="/Users/{username}/Library/Developer/Xamarin/Archives"/>
<add key="commandPath" value="/Library/Frameworks/Mono.framework/Versions/Current/Commands/mono-symbolicate"/>

Then I ran the service through Visual Studio for Mac:

Thread started: #3 Thread started: #4 Thread started: #5 Listening on http://localhost:5000 Thread started: #6 Thread started: #7 Topshelf.Hosts.ConsoleRunHost Information: 0 : The MonoSymbolicateHelper service is now running, press Control+C to exit.

I believe the Chrome Extension is listening to the local service, as I see a thread start and finish in the logs every time I refresh a HockeyApp page. However, the lines of code within my application aren't showing up in the stack traces. The native Android lines of code are showing up, so that's a good first step.

Here is an example url:

https://rink.hockeyapp.net/manage/apps/77910/app_versions/318/crash_reasons/185330792?type=crashes

And here is the stack trace:

Package: com.rpr.mobile Version Code: 350 Version Name: 1.64.04 Android: 7.0 Android Build: NRD90M.G920AUCS6EQH1 Manufacturer: samsung Model: SAMSUNG-SM-G920A Thread: main-1 CrashReporter Key: AD59744D-1AC0-940A-5692-0FE867F14029CEA88132 Start Date: Wed Sep 06 09:45:54 MDT 2017 Date: Wed Sep 06 12:53:25 MDT 2017 Format: Xamarin

Xamarin caused by: android.runtime.JavaProxyThrowable: System.FormatException: Input string was not in a correct format. at System.Number.StringToNumber (System.String str, System.Globalization.NumberStyles options, System.Number+NumberBuffer& number, System.Globalization.NumberFormatInfo info, System.Boolean parseDecimal) [0x00057] in <09db955cb74d4f0c96e9c92479f5e91f>:0 at System.Number.ParseInt32 (System.String s, System.Globalization.NumberStyles style, System.Globalization.NumberFormatInfo info) [0x00015] in <09db955cb74d4f0c96e9c92479f5e91f>:0 at System.Int32.Parse (System.String s, System.IFormatProvider provider) [0x00008] in <09db955cb74d4f0c96e9c92479f5e91f>:0 at System.Convert.ToInt32 (System.String value) [0x0000b] in <09db955cb74d4f0c96e9c92479f5e91f>:0 at RPR.Mobile.Droid.Adapters.PropertyDetails.HomeFactsListAdapter.UpdateView (Android.Views.View view, RPR.Mobile.Shared.Entities.PropertyDetails.HomeFact homeFact, System.Int32 position, Android.Views.ViewGroup parent) [0x00480] in :0 at RPR.Mobile.Droid.Adapters.BaseListAdapter`1[T].GetView (System.Int32 position, Android.Views.View convertView, Android.Views.ViewGroup parent) [0x000af] in :0 at Android.Widget.ArrayAdapter.n_GetView_ILandroid_view_View_Landroid_viewViewGroup (System.IntPtr jnienv, System.IntPtr native__this, System.Int32 position, System.IntPtr native_convertView, System.IntPtr native_parent) [0x00018] in <07ddc444d6054c7782b4277d79d0163e>:0 at (wrapper dynamic-method) System.Object:ff0ffac8-bbbc-4064-82f8-964654ef622d (intptr,intptr,int,intptr,intptr) at md5477c1ae231ff69a123e5fd60d990b747.BaseListAdapter_1.n_getView(Native Method) at md5477c1ae231ff69a123e5fd60d990b747.BaseListAdapter_1.getView(BaseListAdapter_1.java:73) at android.widget.AbsListView.obtainView(AbsListView.java:3238) at android.widget.ListView.makeAndAddView(ListView.java:2147) at android.widget.ListView.fillDown(ListView.java:767) at android.widget.ListView.fillFromTop(ListView.java:833) at android.widget.ListView.layoutChildren(ListView.java:1872) at android.widget.AbsListView.onLayout(AbsListView.java:3008) at android.view.View.layout(View.java:18804) at android.view.ViewGroup.layout(ViewGroup.java:5951) at android.widget.LinearLayout.setChildFrame(LinearLayout.java:1741) at android.widget.LinearLayout.layoutVertical(LinearLayout.java:1585) at android.widget.LinearLayout.onLayout(LinearLayout.java:1494) at android.view.View.layout(View.java:18804) at android.view.ViewGroup.layout(ViewGroup.java:5951) at android.widget.LinearLayout.setChildFrame(LinearLayout.java:1741) at android.widget.LinearLayout.layoutVertical(LinearLayout.java:1585) at android.widget.LinearLayout.onLayout(LinearLayout.java:1494) at android.view.View.layout(View.java:18804) at android.view.ViewGroup.layout(ViewGroup.java:5951) at android.widget.ListView.setupChild(ListView.java:2260) at android.widget.ListView.makeAndAddView(ListView.java:2140) at android.widget.ListView.fillSpecific(ListView.java:1470) at android.widget.ListView.layoutChildren(ListView.java:1911) at android.widget.AbsListView.onLayout(AbsListView.java:3008) at android.view.View.layout(View.java:18804) at android.view.ViewGroup.layout(ViewGroup.java:5951) at android.widget.RelativeLayout.onLayout(RelativeLayout.java:1079) at android.view.View.layout(View.java:18804) at android.view.ViewGroup.layout(ViewGroup.java:5951) at android.widget.FrameLayout.layoutChildren(FrameLayout.java:323) at android.widget.FrameLayout.onLayout(FrameLayout.java:261) at android.view.View.layout(View.java:18804) at android.view.ViewGroup.layout(ViewGroup.java:5951) at android.support.v4.widget.DrawerLayout.onLayout(DrawerLayout.java:1193) at android.view.View.layout(View.java:18804) at android.view.ViewGroup.layout(ViewGroup.java:5951) at android.widget.FrameLayout.layoutChildren(FrameLayout.java:323) at android.widget.FrameLayout.onLayout(FrameLayout.java:261) at android.view.View.layout(View.java:18804) at android.view.ViewGroup.layout(ViewGroup.java:5951) at com.android.internal.widget.ActionBarOverlayLayout.onLayout(ActionBarOverlayLayout.java:493) at android.view.View.layout(View.java:18804) at android.view.ViewGroup.layout(ViewGroup.java:5951) at android.widget.FrameLayout.layoutChildren(FrameLayout.java:323) at android.widget.FrameLayout.onLayout(FrameLayout.java:261) at com.android.internal.policy.DecorView.onLayout(DecorView.java:887) at android.view.View.layout(View.java:18804) at android.view.ViewGroup.layout(ViewGroup.java:5951) at android.view.ViewRootImpl.performLayout(ViewRootImpl.java:2655) at android.view.ViewRootImpl.performTraversals(ViewRootImpl.java:2371) at android.view.ViewRootImpl.doTraversal(ViewRootImpl.java:1522) at android.view.ViewRootImpl$TraversalRunnable.run(ViewRootImpl.java:7098) at android.view.Choreographer$CallbackRecord.run(Choreographer.java:927) at android.view.Choreographer.doCallbacks(Choreographer.java:702) at android.view.Choreographer.doFrame(Choreographer.java:638) at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:913) at android.os.Handler.handleCallback(Handler.java:751) at android.os.Handler.dispatchMessage(Handler.java:95) at android.os.Looper.loop(Looper.java:154) at android.app.ActivityThread.main(ActivityThread.java:6682) at java.lang.reflect.Method.invoke(Native Method) at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1520) at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1410)

[kiliman]

@justintoth Thanks for the report. First of all, lets make sure the service is running properly.

Can you install Postman (or similar) and submit a request to http://localhost:5000/symbolicate (like I show in the README)?

It should give you back the clean stack trace. If so, then we know it is finding the Archives and running the command properly.

NOTE: Those Java files are part of the actual stack trace, since they come from the JVM, not the .NET side, so those are not part of the mono-symbolicate process.

Now check the Chrome dev console for the extension (you can inspect the background page from the Extensions list). See if there are any errors. Also press F12 on the HockeyApp page to see if there are any errors from the content script.

[justintoth]

When running in postman, it gives back the stack trace but with all 0's for the line numbers.

So the issue seems to be related to the helper (or something in my environment), rather than with the chrome extension.

[kiliman]

What that usually means is that it couldn't find the symbols for that specific versionCode.

If you look through the Archives folder, you'll see that there are folders by date. Then there is a folder for each app build. If you open that, you'll see a file named archive.xml. This contains the package name and version code for the build.

During startup, the helper service enumerates all these folders and creates a list of paths by package/version. When you call /symbolicate, it will use the package and version to determine which mSYM path to pass to mono-symbolicate.

Double-check to make sure you have an archive for the package and version you are passing.

Also, in your stack trace, the .NET entries are denoted by [entry] in <hash>:0. Make sure you have a folder that corresponds with the <hash> entry in the mSYM folder of the archive. This is what the mono-symbolicate tool uses to get the correct symbols.

Hopefully we can figure out what's going on.

[justintoth]

The archive.xml file matches up:

<?xml version="1.0" encoding="utf-8"?>
<Archive>
  <Name>RPR Mobile</Name>
  <PackageName>com.rpr.mobile</PackageName>
  <PackageVersionCode>349</PackageVersionCode>
  <PackageVersionName>1.64.03</PackageVersionName>
  <CreationDate>636385047704908850</CreationDate>
  <SolutionName>RPR Mobile - Android</SolutionName>
  <SolutionPath>/Users/justintoth/Documents/rpr-mobile/RPR Mobile - Android.sln</SolutionPath>
  <InsightsApiKey />
  <Status></Status>
  <Configuration>
    <DebugMode>true</DebugMode>
  </Configuration>
  <Comment />
  <LastUsedKeystore>/Users/justintoth/Library/Developer/Xamarin/Keystore/prod-key/prod-key.keystore</LastUsedKeystore>
  <TimeStampingAuthority />
  <LastInsightsUploadDate>0</LastInsightsUploadDate>
</Archive>

In the stack trace, the code lines related to my application have a hash of d69074b01bdc4aee9b338c440e2a3b69 . I'm not seeing a folder that has that hash...

[kiliman]

Is it possible that you have 2 different builds of version 349? The service enumerates by folder name and last one it finds is the one it uses (overwrites previous entry in dictionary).

Try to search for the d69074b01bdc4aee9b338c440e2a3b69 folder and see if it can be found.

I have a Mac but haven't tried this there... when I get a chance I'll see if there's something different. Perhaps I'm making an assumption that works on Windows but not on the Mac.

[justintoth]

That's the only 349 build. I double checked and the only folders in the Archives folder match up with the builds that I see in Visual Studio.

I tried searching in Finder for d69074b01bdc4aee9b338c440e2a3b69 and found nothing.

[kiliman]

Ok, so did you enable the full symbols on the project prior to Aug 16, which is when 349 was built? Without the symbols on release builds, mono-symbolicate will be pretty useless. This is not enabled by default, and I don't think there's a UI for it yet. You have to manually update the .csproj file.

[justintoth]

Yes, below is my PropertyGroup. I added the debug support on July 19. Do you think the capitalization could be an issue? MonoSymbolArchive is the only one that is capitalized in my config, I must've copy/pasted that from somewhere else.

<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release-Prod|AnyCPU' ">
    <OutputPath>bin\Release</OutputPath>
    <ErrorReport>prompt</ErrorReport>
    <WarningLevel>4</WarningLevel>
    <ConsolePause>false</ConsolePause>
    <AndroidUseSharedRuntime>false</AndroidUseSharedRuntime>
    <AndroidLinkSkip>System.Core;System.Runtime.Serialization;Android.Gms.Gcm</AndroidLinkSkip>
    <AndroidSupportedAbis>armeabi-v7a;arm64-v8a;armeabi;x86;x86_64</AndroidSupportedAbis>
    <JavaMaximumHeapSize>1G</JavaMaximumHeapSize>
    <AndroidLinkMode>SdkOnly</AndroidLinkMode>
    <AndroidEnableMultiDex>true</AndroidEnableMultiDex>
    <MonoSymbolArchive>True</MonoSymbolArchive>
    <DebugSymbols>true</DebugSymbols>
    <DebugType>full</DebugType>
    <Optimize>true</Optimize>
  </PropertyGroup>

[kiliman]

It's really hard to say. I would recommend that you go through the <hash> folders and make sure that your app assembly is there. Xamarin will generate a separate folder for each assembly in your app.

Looks like I may have to build my sample app on the Mac and make sure everything is working end-to-end.

[justintoth]

There are 16 hash folders for this version, 4 of which have my application's dll and pdb. The rest have either mono assemblies or my shared project assembly. I tried changing the hash in the exception stack trace to each of the 4 hash folders, however it still returned line numbers of 0 each time. Very strange that the hashes aren't matching up...