Hi Rolf, Because of the size, I'll send to you directly. About --noregistrar, will this do not show anymore the "wonderful" clues like 7 MyApp 0x007862c6 native_to_managed_trampoline_MyApp_FormLogin_ViewWillAppear (registrar.m:10154)?
I think this was the only thing to give me some clues in 2 months The second thing is that I don't know yet when this will appear again in some user, but can try to make the user who begin to have this problem to change the version for one compiled with --noregistrar. And, I must to confess I put some try/catch with catch login things on test flight to get this log and bypass what is executed on ViewDidLoad and ViewWillAppear to try to workaround and get some info. So, is someone have this in near future, I can remove try/catches and make a version with noregistrar. Thanks, Karl From: Rolf Bjarne Kvinge <[email protected]> Date: sexta-feira, 14 de setembro de 2012 05:38 To: Karl Heinz Brehme Arredondo <[email protected]> Cc: "[email protected]" <[email protected]> Subject: Re: [MonoTouch] App crashing at startup after a crash inside app Hi, On Thu, Sep 13, 2012 at 2:35 AM, Karl Heinz Brehme Arredondo <[email protected]> wrote: > Hi, > > I have an app that runs fine. But in some rare times (not so rare, maybe 10 > cases per month) , something happens that crashes the App, and the it doesn't > open anymore. > > Today I succeed to get a crash log from TestFlight for a case of that. User > try to open app and it doesn't open anymore. Before that is was normal. > Normally this could be some data, field or table missing, but I got a copy of > sqlite DB and it runs OK in another place (device or simulator). > > The strange thing is the failure appear to be in a UITextField (in truth in a > custom UITxtField), but I can't figure out why since it runs OK from almost 2 > years indeed, is in the login screen, the first view controller, the first > thing made since betas. > > So I can see that ViewWillAppear has some UITextView get Text, and that could > be some null object reference on it. BUT isn't below missing the ViewDidLoad > thing? Is there a way to do not log this or do not being fired the > ViewDidLoad? Remembering that application run normally. Just in a few cases > that some users report that and the way is to uninstall and reinstall, loosing > all data non transferred to server. If I removed ViewWillAppear and > ViewDidLoad and application returned to life. I put it again and no mo error > So now to do more tests I need another occurrence of that problem. > > 1. 0 MyApp 0x00003102 testflight_backtrace + 158 > 2. 1 MyApp 0x00003d2c TFSignalHandler + 244 > 3. 2 libsystem_c.dylib 0x34c857ec _sigtramp + 48 > 4. 3 MyApp 0x0006f067 MonoTouch_UIKit_UITextField_get_Text + 99 > 5. 4 MyApp 0x0033d493 > wrapper_runtime_invoke_object_runtime_invoke_dynamic_intptr_intptr_intptr_intp > tr + 199 > 6. 5 MyApp 0x007cf406 mono_jit_runtime_invoke (mini.c:5792) > 7. 6 MyApp 0x0084afd2 mono_runtime_invoke (object.c:2788) > 8. 7 MyApp 0x007862c6 > native_to_managed_trampoline_MyApp_FormLogin_ViewWillAppear > (registrar.m:10154) > 9. 8 UIKit 0x306d7b94 -[UIViewController _setViewAppearState:isAnimating:] + > 144 > 10. 9 UIKit 0x306da8fa -[UINavigationController > _startTransition:fromViewController:toViewController:] + 814 > 11. 10 UIKit 0x306da502 -[UINavigationController > _startDeferredTransitionIfNeeded] + 250 > 12. 11 UIKit 0x3077a39c -[UINavigationController defaultFirstResponder] + 124 > 13. 12 UIKit 0x306c03b4 -[UIResponder(Internal) _deepestDefaultFirstResponder] > + 24 > 14. 13 UIKit 0x306c03d0 -[UIResponder(Internal) _deepestDefaultFirstResponder] > + 52 > 15. 14 UIKit 0x306c0262 -[UIResponder(Internal) > _promoteDeepestDefaultFirstResponder] + 30 > 16. 15 UIKit 0x306c023e -[UIWindow makeKeyWindow] + 382 > 17. 16 MyApp 0x0008e107 > wrapper_managed_to_native_MonoTouch_ObjCRuntime_Messaging_void_objc_msgSend_in > tptr_intptr + 67 > 18. 17 MyApp 0x005f5ca7 > MyApp_AppDelegate_FinishedLaunching_MonoTouch_UIKit_UIApplication_MonoTouch_Fo > undation_NSDictionary + 371 > 19. 18 MyApp 0x0033d493 > wrapper_runtime_invoke_object_runtime_invoke_dynamic_intptr_intptr_intptr_intp > tr + 199 > 20. 19 MyApp 0x007cf406 mono_jit_runtime_invoke (mini.c:5792) > 21. 20 MyApp 0x0084afd2 mono_runtime_invoke (object.c:2788) > 22. 21 MyApp 0x0076687c > native_to_managed_trampoline_MyApp_AppDelegate_FinishedLaunching > (registrar.m:654) > 23. 22 UIKit 0x306cdcaa -[UIApplication > _callInitializationDelegatesForURL:payload:suspended:] + 1182 > 24. 23 UIKit 0x306c77dc -[UIApplication > _runWithURL:payload:launchOrientation:statusBarStyle:statusBarHidden:] + 408 > 25. 24 UIKit 0x30695ac2 -[UIApplication handleEvent:withNewEvent:] + 1010 > (cut due to size) I had a second look at the stack trace, and now I realize it's all wrong, it has nothing to do with UITextField nor your subclass, it looks like something worse, frame #3 shouldn't be a call to MonoTouch_UIKit_UITextField_get_Text, it should be a call to MyApp_FormLogin_ViewWillAppear (frame #7 is the method where we transition from native code to managed code, but it is not the actual managed implementation of the method). Can you also attach the complete crash report from TestFlight (in particular I'm interested in the addresses where the app and dylibs were mapped in the process space)? Also, can you try rebuilding your application with --noregistrar (add it to the additional mtouch arguments in the projects iPhone Build options) to see if it makes a difference? Rolf > > Thanks, > > Karl > > > _______________________________________________ > MonoTouch mailing list > [email protected] > http://lists.ximian.com/mailman/listinfo/monotouch >
_______________________________________________ MonoTouch mailing list [email protected] http://lists.ximian.com/mailman/listinfo/monotouch
