43

We've hooked up TestFlight and the TestFlight SDK with MonoTouch and so far it's working great.

One thing we've noticed is that the crash reports are more geared towards Obj-C apps.

They look like this after you upload a zipped dSYM file:

0 OurApp 0x007a7116 testflight_backtrace + 170
1 OurApp0x007a7c3c TFSignalHandler + 208
2 libsystem_c.dylib 0x34f68538 _sigtramp + 48
3 libsystem_c.dylib 0x34f5df5a pthread_kill + 54
4 libsystem_c.dylib 0x34f56fea abort + 94
5 OurApp 0x007793b3 monoeg_g_logv (goutput.c:137)
6 OurApp 0x0077941f monoeg_g_log (goutput.c:147)
7 OurApp 0x005f1393 get_numerous_trampoline (aot-runtime.c:3447)
8 OurApp 0x005f1b2f mono_aot_get_imt_thunk (aot-runtime.c:3576)
9 OurApp 0x006e2c83 initialize_imt_slot (object.c:1247)
10 OurApp 0x006e321f build_imt_slots (object.c:1371)
11 OurApp 0x006e356f mono_vtable_build_imt_slot (object.c:1439)
12 OurApp 0x005fcf83 mono_convert_imt_slot_to_vtable_slot (mini-trampolines.c:198)
13 OurApp 0x005fd50f common_call_trampoline (mini-trampolines.c:333)
14 OurApp 0x005fe573 mono_vcall_trampoline (mini-trampolines.c:644)
15 OurApp 0x0056a68f generic_trampoline_vcall (mscorlib.dll.6.s:194345)
16 OurApp 0x00416b4f System_Collections_Generic_List_1__ctor_System_Collections_Generic_IEnumerable_1_T (mscorlib.dll.6.s:32014)
17 OurApp 0x0026955b System_Linq_Enumerable_ToList_TSource_System_Collections_Generic_IEnumerable_1_TSource (System.Core.dll.6.s:1917)

So you can tell the general C# function where the crash occurred. (Note: this crash was a bug in MonoTouch 5.0.1 where Linq generics were messed up, seems to be fixed in 5.0.2)

It would be nice to get the full C# stack trace in here, any thoughts on how to do that? I could hook into AppDomain.UnhandledException and put a try-catch around my static void Main method, but wondered if there is a way to report the stack trace out to TestFlight.

jonathanpeppers
  • 26,115
  • 21
  • 99
  • 182
  • 1
    a small note to confirm that 5.0.1 had a regression (i.e. 5.0 was fine) which causes `EngineExecutionException` to be thrown in some cases. This was fixed in 5.0.2. – poupou Nov 28 '11 at 18:26
  • 1
    I have been exploring this problem too and I haven't come up with anything. (I would settle for just the line number to be honest.) – vlad259 Dec 21 '11 at 11:36
  • 2
    I was thinking about trying to send full exception details as a checkpoint (even though that's not what it's for). I'm not sure how it will look on TestFlight, though. – jonathanpeppers Dec 21 '11 at 13:09
  • 1
    Note: putting a stacktrace through a checkpoint looks horrendous, wouldn't recommend it as a solution. – jonathanpeppers Jan 04 '12 at 13:06
  • I believe you can set a custom exception handler, which the TestFlight SDK demonstrates how to do. You could probably retrieve your function stack trace thingy there and send it to TestFlight using a feedback controller or something. – Tristan Jan 07 '12 at 05:39
  • These crashes usually mean the app quits (so no chance to show a feedback controller). Can you post a link to the custom exception handler doc you mention? Only think I found was a fork on GitHub here: https://github.com/danielctull/TestFlight-SDK – jonathanpeppers Jan 08 '12 at 15:51
  • Did the latest release correct this? http://support.testflightapp.com/discussions/sdk/37-no-line-numbers-in-stacktrace – Joshua Drake Jan 11 '12 at 16:16
  • 1
    Yeah, I was using the latest version mentioned on that discussion, I uploaded a dSym file which produced the output above in my question. My issue is due to us using MonoTouch and wanting to see C#-style stacktraces, which we can produce ourselves and report--there is just not a way we know how to pass a custom stack trace to TestFlight. – jonathanpeppers Jan 11 '12 at 20:33
  • I read this as 'I want MonoTouch to crash more effectively'. ;) – nicodemus13 Feb 05 '12 at 20:45
  • We had the same problem and ended up going for the try/catch around `Main` statement, dumping the C# stack traces to a log file and sending that to our server. – Timothy Groote Feb 06 '12 at 12:34
  • 1
    This is an old question - but for anyone searching, we've had very good luck with Raygun.io in our Monotouch applications. It collects a much better and complete stack trace. – Ender2050 Aug 23 '14 at 16:17
  • @Ender2050, we use it too. Agreed. – jonathanpeppers Aug 23 '14 at 18:28

1 Answers1

3

I'm not familiar with MonoTouch, but what about using the Remote Logging features of the TestFlight SDK?

bryanjclark
  • 6,247
  • 2
  • 35
  • 68
  • I was using MonoTouch binding here: https://github.com/ayoung/monotouch-testflight Which I don't know if he has the TFlog Obj-C function setup for use from C#. I will try to bind all missing methods myself and see if any of them solve this issue. – jonathanpeppers Feb 08 '12 at 12:53
  • 1
    Found a newer one (commit on Feb 01) here: https://github.com/mono/monotouch-bindings/tree/master/TestFlight Going to try it. – jonathanpeppers Feb 08 '12 at 12:59
  • 1
    Ok, using `TestFlight.Log()` works pretty well. You have to log exceptions in `AppDomain.UnhandledException` and in `static void Main()`. The C# stacktrace won't show up as a crash report, but you can view it in the log of the session. – jonathanpeppers Mar 14 '12 at 12:51
  • What are you sending to TestFlight.Log? – Piotr Tomasik May 23 '12 at 00:58