Crash reports don't actually tell me which exception was thrown...

[icnatejackson]

I've deployed an app to HockeyApp which uses these bindings. I've also uploaded the .dSYM file that Xamarin Studio creates for my AD-HOC build. When a crash report comes into Hockeyapp, they do run the process to resurrect the stack trace that occurred, and I can see the line of code that had the unhandled exception... But, the crash report doesn't actually tell me what the exception was. Everything comes to HockeyApp with:

Exception Type: SIGABRT

I have followed the guidance in the readme.md of these bindings regarding the steps required in AppDelegate.

Here is a sample crash report from HocekApp. Line 10 is my code that was crashing due to a LINQ issue... but I'd never know that. Is there something else I need to do to set up my project to get the actual exception message in my Crash Reports?

Thread 0 Crashed:
1 libsystem_kernel.dylib _pthread_kill + 8
2 libsystem_c.dylib _abort + 95
3 EPRDiOS monotouch_throw_monotouch_exception (monotouch-glue.m:1369)
4 EPRDiOS mono_invoke_unhandled_exception_hook (mini-exceptions.c:2745)
5 EPRDiOS mono_thread_abort_dummy (mini.c:2809)
6 EPRDiOS mono_handle_exception_internal + 2149
7 EPRDiOS mono_handle_exception (mini-exceptions.c:1972)
8 EPRDiOS mono_arm_throw_exception (exceptions-arm.c:162)
9 EPRDiOS throw_exception + 68
10 EPRDiOS EPRD_BL_Managers_EPRDRegisterManager_OnRegisterSelected_int (EPRDRegisterManager.cs:97)
11 EPRDiOS EPRD_AL_TableSource_RowSelected_MonoTouch_UIKit_UITableView_MonoTouch_Foundation_NSIndexPath (TableSource.cs:137)
12 EPRDiOS wrapper_runtime_invoke_object_runtime_invoke_dynamic_intptr_intptr_intptr_intptr + 200
13 EPRDiOS mono_jit_runtime_invoke (mini.c:6457)
14 EPRDiOS mono_runtime_invoke (object.c:2827)
15 EPRDiOS native_to_managed_trampoline_EPRD_AL_TableSource_RowSelected (registrar.m:1809)
16 UIKit -[UITableView _selectRowAtIndexPath:animated:scrollPosition:notifyDelegate:] + 877
17 UIKit -[UITableView _userSelectRowAtPendingSelectionIndexPath:] + 157
18 Foundation __NSFireDelayedPerform + 451
19 CoreFoundation __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION + 15
20 CoreFoundation CFRunLoopDoTimer + 273
21 CoreFoundation __CFRunLoopRun + 1233
22 CoreFoundation _CFRunLoopRunSpecific + 357
23 CoreFoundation _CFRunLoopRunInMode + 105
24 GraphicsServices _GSEventRunModal + 75
25 UIKit _UIApplicationMain + 1121
26 EPRDiOS wrapper_managed_to_native_MonoTouch_UIKit_UIApplication_UIApplicationMain_int_string___intptr_intptr (:1)
27 EPRDiOS MonoTouch_UIKit_UIApplication_Main_string___string_string (UIApplication.cs:38)
28 EPRDiOS EPRD_iOS_Application_Main_string (Main.cs:16)
29 EPRDiOS wrapper_runtime_invoke_object_runtime_invoke_dynamic_intptr_intptr_intptr_intptr + 200
30 EPRDiOS mono_jit_runtime_invoke (mini.c:6457)
31 EPRDiOS mono_runtime_invoke (object.c:2827)
32 EPRDiOS mono_runtime_exec_main (object.c:4052)
33 EPRDiOS mono_runtime_run_main (object.c:3678)
34 EPRDiOS mono_jit_exec (driver.g.c:962)
35 EPRDiOS main (main.m:489)

[gaearon]

Hi, unfortunately this is the best you can get with an unmanaged crash reporter.

You need native stack trace for non-managed errors that happen due to some object you need being GC'd ("unrecognized selector sent" errors), don't get caught because they happen inside a "block" called from ObjC or even due to some bug in apple code (there's been a lot of NSLayoutSomething crashes recently).

Still, I agree correct managed stack traces are often much more useful. So I collect them both.

I'm using HockeyApp's feature that allows to attach arbitrary strings to its crash reports. For this, I made a custom class:

class CrashManagerDelegate : BITCrashManagerDelegate {
    public override string GetApplicationLog (NSObject crashManager)
    {
        if (!File.Exists (Profiler.PreviousTraceFile))
            return string.Empty;

        var lines = File.ReadAllLines (Profiler.PreviousTraceFile);
        return string.Join (
            Environment.NewLine,
            lines.Skip (Math.Min (0, lines.Length - 100))
        );
    }
}

and I configure HockeyApp with an instance of this class:

manager.Configure (HockeyAppId, new CrashManagerDelegate ());

Now, of course I need to dump managed stack trace to file:

    static void Main (string [] args)
    {
if !DEBUG
        try {
endif
            UIApplication.Main (args, null, "AppDelegate");
if !DEBUG
        } catch (Exception ex) {
            Profiler.Trace (ex);
            throw;
        }
endif
    }

And this is a part of my Profiler helper class that I'm calling to record exception:

    private static readonly Lazy<string> _previousTraceFile = new Lazy<string> (DeterminePreviousLog);
    private static readonly Lazy<StreamWriter> _traceWriter = new Lazy<StreamWriter> (CreateTraceWriter);
    private static string _traceFile;

    public static string PreviousTraceFile {
        get { return _previousTraceFile.Value; }
    }

    private static string TraceDirectory {
        get {
            return Path.Combine (
                Environment.GetFolderPath (Environment.SpecialFolder.MyDocuments),
                "..",
                "Library",
                "Blackbox"
                );
        }
    }

    private static string DeterminePreviousLog ()
    {
        var dir = new DirectoryInfo (TraceDirectory);
        if (!dir.Exists)
            return null;

        return dir.GetFiles ()
            .OrderByDescending (f => f.LastWriteTime)
            .Select (f => f.FullName)
            .FirstOrDefault ();
    }

    private static StreamWriter CreateTraceWriter ()
    {
        var dir = new DirectoryInfo (TraceDirectory);
        if (!dir.Exists) {
            dir.Create ();
        } else {
            // Force previous filename to be materialized
            var previous = _previousTraceFile.Value;
            Console.WriteLine ("Previous log file is {0}", previous);
        }

        _traceFile = Path.Combine (TraceDirectory, Path.GetRandomFileName ());
        Console.WriteLine ("Created {0}", _traceFile);

        return new StreamWriter (_traceFile, false) {
            AutoFlush = true
        };
    }

    private static void Trace (string format, object [] args)
    {
        if (!TraceToFile)
            return;

        var message = format;
        if (args != null) {
            message = string.Format (message, args);
        }

        var moscowTime = DateTime.UtcNow.AddHours (4);
        var formatted = string.Format ("[{0:HH:mm:ss}] {1}", moscowTime, message);

        _traceWriter.Value.WriteLine (formatted);
    }

It's not perfect but I hope you find it useful!

In HockeyApp webapp, I open a crash log, and each has a Description tab. This is where this text (managed stack trace in our case) will go.

[icnatejackson]

Dan... thanks for this. I'm not going to claim that I understand this:

lines.Skip (Math.Min (0, lines.Length - 100)

and I assume you have some additional mechanisms in place to eventually remove these trace files from storage??

[gaearon]

@icnatejackson

lines.Skip (Math.Min (0, lines.Length - 100)

Take last 100 lines or less.

(This is usually enough for stack traces, and since we do occasional logging, can help with understanding the cause if it's not clear from stack trace, or if the program crashed without having time to record a managed stack trace).

Yes, you'd just need to also delete all files from that directory except current trace file, after you read the previous one in HockeyApp delegate.

[icnatejackson]

@gaearon Ah... OK. Thanks for your reasoning around only capturing the last 100 lines. It makes sense I guess. I'd have to review some sample stack traces to see if that threshold make sense for me.

These bindings are a blessing and have already saved my bacon a couple times even without my having access to the actual exception message. I'll work to implement something similar to the approach you've outlined here to see if it helps clear things up on my end.

Many thanks again for the bindings and this extra push.

[gaearon]

@icnatejackson Sure, thanks for coming by.

I think I'll close this issue when I get around to adding a similar section to README so future users don't get confused.

[gaearon]

Added a link to this issue to README. Closing.

[icnatejackson]

For anyone reading these great instructions from @gaearon , it might be worth noting that the custom crash data that you're attaching using the methods outlined here will appear in HockeyApp, but not on the crash's "Overview screen" where you see text similar to my initial question.

To see the custom text (the last 100 lines of the managed stack trace in the example @gaearon provided), you have to go to the Crash Group's "Crash Logs" tab, scroll down to the "Data" section, then finally click the "Description" tab.

This is likely covered in the HockeyApp SDK docs, but, heck, who reads docs?

[gaearon]

Thank you for clarification!