Releasing app with debug symbols ?

2»

Answers

  • RolfBjarneKvingeRolfBjarneKvinge USXamarin Team Xamurai

    Another thing you can do is to run Apple's symbolicatecrash [1] script with the -v argument, it'll tell you exactly what it does (it uses atos just like you're trying to do), and maybe you'll be able to figure out exactly the way to do it. In the worst case scenario the symbolicatecrash script is written in perl (i.e. you can read it to make sense of what it's doing).

    [1] It's inside the Xcode.app bundle somewhere, but the exact location varies between Xcode releases. For Xcode 5.1.1 it's /Applications/Xcode.app/Contents/SharedFrameworks/DTDeviceKitBase.framework/Versions/A/Resources/symbolicatecrash

  • ThomasWongThomasWong USMember

    Hi there,

    I am ok with pushing the build with debugging enabled so that we get the managed stack trace line numbers, however recently the Xcode won't publish an app with debugging enabled because it references NSZombieEnabled (http://stackoverflow.com/questions/25432708/ios-error-on-publishing-ios-application-from-xcode).

    Is there a way to publish the "debugging enabled" build to app store without triggering this?

    Thanks

  • RolfBjarneKvingeRolfBjarneKvinge USXamarin Team Xamurai

    @ThomasWong: I've removed our NSZombieEnabled usage, but it will take a while until it reaches a release (it'll probably be Xamarin.iOS 8.8, but it depends a bit since apparently Apple is preparing several point releases this year, which could skew our numbering).

  • Does 'enable debugging' do anything else besides enable/disable symbols? Is there a short wait, for example, at start up looking for the debugger?

  • BernieHabermeierBernieHabermeier USUniversity ✭✭
    edited February 2015

    @RolfBjarneKvinge: I finally spent some more time with this idea. I think I'm getting closer, but unfortunately I think there is something not quite right (at least with the resulting line numbers)

    I have a crash in a trivial place (I found it was a null pointer exception), but it should serve as a good test for trying to get the filename / method / line number from the dSYM of the release build.

    here is the crash log

    The crash was due to a referenced null object on line 94 in this file. Specifically placeBundle.Image was null in this case.

    I wrote a small ruby script to test getting data back from the dSYM file with atos. It's using some hard-coded values, but it will do for now to test out the method of getting the data back.

    I'm looking at native_trace_ips, as well as "trace_ips", and finally I do what I call a "desperate" search at / around the address I think should be the culprit. The output of the script is here.

    Things look somewhat promising (though I'd love to demangle the C# class/method names, which I'm sure could be done. The line I'm looking at is (8th one down from native_trace_ips stack):
    Client_Core_ViewModels_AddingPlaceCaptionViewModel__get_DoneCommandm__0 (in ClientTouch) (AddingPlaceCaptionViewModel.cs:43)

    I like the fact that it's found Client_Core_ViewModels_AddingPlaceCaptionViewModel__get_DoneCommand though that's not super impressive -- I had that information from the originating crash log from the 'Application Specific Information' section. It's also nice to see that it got the filename right (AddingPlaceCaptionViewModel.cs).

    What's foobar though is the line number -- this is an essential part of the whole objective -- getting it down to the line number.

    The thing is -- in the "desperate" search section I just poke around the memory region with atos to see what line numbers various addresses would fall into and it really maps the methods to the wrong line numbers. Everywhere.

    So my thesis is that even if there was a minor thing wrong with my address math -- it would not matter. The mapping that atos is reporting between methods and filename/line numbers isn't correct. Seems like the filename is OK -- but no matter what I do to arrive at the input address to atos, the line numbers will be bad:

    0x24c9a4 -> 0x18b9a4: Client_Core_ViewModels_AddingPlaceCaptionViewModel_set_IsPowerUser_bool (in ClientTouch) (AddingPlaceCaptionViewModel.cs:93) 0x24c9c4 -> 0x18b9c4: Client_Core_ViewModels_AddingPlaceCaptionViewModel_set_IsPowerUser_bool (in ClientTouch) (AddingPlaceCaptionViewModel.cs:95)

    Clearly AddingPlaceCaptionViewModel.cs:95 has nothing to do with the setter of IsPowerUser. Just like the getter of DoneCommand is nowhere near line 43.

  • RolfBjarneKvingeRolfBjarneKvinge USXamarin Team Xamurai

    @BernieHabermeier: so it looks like we have a bug somewhere - https://bugzilla.xamarin.com/show_bug.cgi?id=19547 - that causes the line numbers in the debug info to be incorrect. I've talked to the engineer who usually works in this area, and he'll have a look and see if he can fix it.

  • BernieHabermeierBernieHabermeier USUniversity ✭✭

    @RolfBjarneKvinge, did you get a chance to talk to the engineer that usually works on this? This has got to affect Xamarin Insights as well. I just got an email from Jon Goldberger (customer support), explaining to me that this is a low priority issue, with only 2 people interested, and oh -- the bug is 9 months old. So you know...

    I hate to stir up trouble, but if it's "community awareness" is what it takes to get traction on this issue, I can get more vocal about raising this issue to the community at large. I don't think that would be constructive, overall -- but certainly, if it's a question of getting more people to support that this needs fixing, I'm sure I can rustle up a larger crowd to express their interest in getting it fixed.

    Please let me know if there is anything I could do to help!

  • RolfBjarneKvingeRolfBjarneKvinge USXamarin Team Xamurai

    @BernieHabermeier, we'll eventually fix this, but the problem is as always how to prioritize issues. We're not saying this particular bug isn't important, but we have a lot of other and more important bugs which we have to fix first.

  • JeffEnderwickJeffEnderwick USMember

    @BernieHabermeier - they're claiming the bug is fixed. Is your technique working?
    Xamerites - this is a basic capability you should be providing as part of your platform.

  • BernieHabermeierBernieHabermeier USUniversity ✭✭

    @JeffEnderwick I believe Xamarin claims it is fixed but that was in alpha channel (April 2). There was an update there after, but unclear if it's on beta or stable. I was unable to build my project on the Alpha channel at the time, and moved on. So long story short -- I'm unsure where it's at. I'll revisit when I have time.

  • JeffEnderwickJeffEnderwick USMember

    @BernieHabermeier - target is 8.10, which is stable now. But no VERIFIED tag. I'll email customer support.

  • BernieHabermeierBernieHabermeier USUniversity ✭✭

    @RolfBjarneKvinge

    you wrote:

    The approach would be to fetch the private native_trace_ips field [1] of the exception object (which is an array of native memory addresses for the stack trace) using reflection and process those addresses using atos.

    [1] https://github.com/mono/mono/blob/master/mcs/class/corlib/System/Exception.cs#L71

    I'm seeing something odd. In the following code, I produce a json output string, but it seems like I get a null value for release builds (with debugging turned off), but do get the native_trace_ips for debug builds (also with debugging turned off). There must be another difference someplace.

    static public class ManagedExceptionReport
    {
    
        static private string ToString(IntPtr[] ips, string indent = "")
        {
            if (ips == null) {
                return "null";
            }
    
            StringBuilder result = new StringBuilder();
            result.AppendLine("[ ");
            for (int idx = 0; idx < ips.Length; idx ++) {
                IntPtr ptr = ips[idx];
                result.AppendLine(string.Format("{0}  \"0x{1}\"{2}", indent, ptr.ToString("x8"), idx == ips.Length - 1 ? "" : ","));
            }
            result.AppendLine(string.Format("{0}]", indent));
            return result.ToString();
    
        }
        static public string GetReport(Exception ex)
        {
            Type baseExeceptionType = Type.GetType("System.Exception");
    
            IntPtr[] native_trace_ips = ex.GetPrivateField<IntPtr[]>("native_trace_ips", baseExeceptionType);
            IntPtr[] trace_ips = ex.GetPrivateField<IntPtr[]>("trace_ips", baseExeceptionType);
    
            StringBuilder result = new StringBuilder();
    
            result.AppendLine("\n{");
            result.Append("  \"native_trace_ips\" : ");
            result.Append(ToString(native_trace_ips, "  "));
            result.Append(",\n");
            result.Append("  \"trace_ips\" : ");
            result.Append(ToString(trace_ips, "  "));
            result.AppendLine("}\n");
    
            return result.ToString();
    
        }
    
    }
    

    I put in a crash on-purpose, and testing on device in a 'debug' build with iOS Debugging Options off, I get:

    Jun 24 16:03:02 Bouncy-Quagoo ClientTouch[542] <Warning>: Exception:Error: 16.89 { "native_trace_ips" : [ "0x0111a399", "0x01119bbb", "0x011136c3", "0x006a0390", "0x004c44fc", "0x00d7e4f0", "0x00d4bf84", "0x0066534c", "0x01126eeb", "0x01173779", "0x010787f5", "0x01086cad", "0x249a789f", "0x23c38fbf", "0x23c383cf", "0x23c36a35", "0x23b843b1", "0x23b841c3", "0x2b16b201", "0x271ee43d", "0x00e07340", "0x00d6f20c", "0x00d6f1cc", "0x00198c7c", "0x0066534c", "0x01126eeb", "0x01173779", "0x01176eb3", "0x01176cf5", "0x01111329", "0x011d6414", "0x010932bd", "0x320f9aaf" ] , "trace_ips" : [ "0x0057d188", "0x00000000", "0x004c44fb", "0x00000000", "0x00d7e4ef", "0x00000000", "0x00d4bf83", "0x00000000", "0x00e07293", "0x00000000", "0x00d6f20b", "0x00000000", "0x00d6f1cb", "0x00000000", "0x00198c7b", "0x00000000" ] }

    and on an Ad-Hoc build with iOS Debugging Options off, I get:

    Jun 24 15:52:10 Bouncy-Quagoo ClientTouch[528] <Warning>: Exception:Error: 14.91 { "native_trace_ips" : null, "trace_ips" : [ "0x100567958", "0x00000000", "0x1004ba01f", "0x00000000", "0x100d17af7", "0x00000000", "0x100ce98e3", "0x00000000", "0x100d98687", "0x00000000", "0x100d09bab", "0x00000000", "0x100d09b6b", "0x00000000", "0x1001c61b3", "0x00000000" ] }

    The compiler is set to Debug Information 'full', and adding the DEBUG CFlags doesn't make a difference. Any idea what's going on there?

  • RolfBjarneKvingeRolfBjarneKvinge USXamarin Team Xamurai

    @BernieHabermeier, I'll have a look and see what I can figure out (but it'll probably take a few days, I just got back from WWDC).

  • BernieHabermeierBernieHabermeier USUniversity ✭✭

    @RolfBjarneKvinge How's it looking? I just got a crash report from a release build, but I got only null pointers back from the above code (for both trace_ips as well as native_trace_ips):

    { "native_trace_ips" : null, "trace_ips" : null }

    It makes me very sad. Oh, woe is me.

  • RolfBjarneKvingeRolfBjarneKvinge USXamarin Team Xamurai

    @BernieHabermeier, first sorry for the late response, I've been really busy working on the upcoming iOS 9.

    I've now tried to reproduce your problem with the current stable version of Xamarin.iOS (8.10.1.74), but no luck (I always get values for both trace_ips and native_trace_ips).

    However there are many things that can affect the build.

    First try changing the build options (in the iOS Build page in the project's properties) to figure out exactly which one is causing a difference between your Debug and Ad-Hoc builds.

  • BernieHabermeierBernieHabermeier USUniversity ✭✭

    @RolfBjarneKvinge Oof that doesn't help so much -- I've been playing with the settings to no avail. I have uploaded my entire source code and have shared with Xamarin. Maybe you can use that source code / project, create an on-purpose crash, make a release ad/hoc build and see what happens?

    As of yesterday @CodyBeyer downloaded our project & source, so you should be able to take a look at what I'm seeing.

  • CodyBCodyB USXamarin Team Xamurai

    @BernieHabermeier sorry i did not see this, I am @byrc on the forums :)

    I am getting this organized for a bugzilla report.

    Thanks!

  • CodyBCodyB USXamarin Team Xamurai

    @BernieHabermeier
    Can you shoot an email off to the normal address, I want to discuss this with out and see if we can get a more streamlined test case.

    Thanks!

  • BernieHabermeierBernieHabermeier USUniversity ✭✭

    @byrc

    Can you shoot an email off to the normal address

    You want me to email [email protected]? Or elsewhere? I'm at [email protected] -- not sure what you mean with "normal address". ?

  • JoeProJoePro CAUniversity ✭✭✭

    @BernieHabermeier Have you been able to get this to work?

  • BernieHabermeierBernieHabermeier USUniversity ✭✭

    No. I often do not get the native_trace_ips, and in cases where I do get it, and I run it against atos with this helper script here: https://gist.github.com/habermeier/d14650819d3ca3e6c5a6 (after adjusting the load offset), it spits out crazy stuff that clearly isn't correct... so I'm no farther along on this than before.

    I need filenames and line numbers in my crash reports, not just the method it crashed in.

  • BernieHabermeierBernieHabermeier USUniversity ✭✭

    @RolfBjarneKvinge‌ / @CodyB Is this problem considered resolved? I'm still running XS 5.10 / Xamarin.iOS 9.6.2.4, and have not yet gotten filenames and line numbers on release builds.

    I've been holding off because I see a good amount of people pulling hair out using XS 6 -- so wanted to give it a few cycles to fully settle down before I switch to the upgrade. Will the upgrade bring filename and line number information for iOS and Android crashes in managed code for release builds?

    === Xamarin Studio Business ===

    Version 5.10.3 (build 51)
    Installation UUID: d0e3606c-dc2f-4964-a816-e733c47a8688
    Runtime:
    Mono 4.2.4 (explicit/71b88f3)
    GTK+ 2.24.23 (Raleigh theme)

    Package version: 402040004
    

    === Xamarin.Profiler ===

    Version: 0.24.0.0
    Location: /Applications/Xamarin Profiler.app/Contents/MacOS/Xamarin Profiler

    === Apple Developer Tools ===

    Xcode 7.3.1 (10188.1)
    Build 7D1014

    === Xamarin.Android ===

    Version: 6.0.4.0 (Xamarin Business)
    Android SDK: /Users/bernie/Library/Developer/Xamarin/android-sdk-macosx
    Supported Android versions:
    2.3 (API level 10)
    4.0.3 (API level 15)
    4.2 (API level 17)
    4.3 (API level 18)
    4.4 (API level 19)
    5.0 (API level 21)
    5.1 (API level 22)
    6.0 (API level 23)

    SDK Tools Version: 24.4.1
    SDK Platform Tools Version: 23.0.1
    SDK Build Tools Version: 23

    Java SDK: /usr
    java version "1.7.0_60"
    Java(TM) SE Runtime Environment (build 1.7.0_60-b19)
    Java HotSpot(TM) 64-Bit Server VM (build 24.60-b09, mixed mode)

    Android Designer EPL code available here:
    https://github.com/xamarin/AndroidDesigner.EPL

    === Xamarin Android Player ===

    Not Installed

    === Xamarin.Mac ===

    Not Installed

    === Xamarin.iOS ===

    Version: 9.6.2.4 (Xamarin Business)
    Hash: d8bedd0
    Branch: master
    Build date: 2016-05-05 17:43:01-0400

    === Xamarin Inspector ===

    Version: 0.3.2.3
    Hash: 1b526e6
    Branch: master
    Build date: Tue Nov 17 20:54:30 UTC 2015

    === Build Information ===

    Release ID: 510030051
    Git revision: f3c0d982165f785772d125f02668370d929014fb
    Build date: 2016-03-24 18:51:31-04
    Xamarin addins: ee5cfd3ecb6b20de47c1d25efb9a9abc101e8ce7
    Build lane: monodevelop-lion-cycle6-c6sr3

    === Operating System ===

    Mac OS X 10.11.5
    Darwin BernieMac.local 15.5.0 Darwin Kernel Version 15.5.0
    Tue Apr 19 18:36:36 PDT 2016
    root:xnu-3248.50.21~8/RELEASE_X86_64 x86_64

Sign In or Register to comment.