Thanks Rolf, well, when the error occur always in some situation, it can be catchable in development environment. The problem is when you have 500 users and he crash just happened 16 times... and all users pass by the same part, doing the same things. But some special condition of maybe style of use/tap things makes the error occur.
And this part exists for more that 1 year and never see that here in dev or tests. Was just to put TestFlight to see some errors never reported or without proofs yet... So each time that must do some test like that to get considerable errors, we must update more than 1000 users, activate helpdesk people etc, also application being auto-updateble with the annoys question if you want to install a new version and some people say: no. With the time passing I'll putting more logs, just have that chance. Maybe identificating most users with that problem to update just them (cold foot). Thanks for tips, Karl Em 21/09/2012, às 21:16, Rolf Bjarne Kvinge escreveu: > Hi, > > On Fri, Sep 21, 2012 at 7:43 PM, Karl Heinz Brehme Arredondo > <[email protected]> wrote: > Hi, > > What could be the meanings of this crashlog? > > 2 libsystem_c.dylib 0x347b67ec _sigtramp + 48 > 3 MyApp 0x0006e06f > MonoTouch_UIKit_UITableView_CellAt_MonoTouch_Foundation_NSIndexPath + 75 > And how can we learn more about that kind of info? > > This tells you that something very bad happened inside > MonoTouch.UIKit.UITableView:CellAt (NSIndexPath path) - but unfortunately > there is not much else you can deduce from those two lines. > > > Some users has this error and I didn't reproduced it yet also knowing now > (from TestFlight.Log) in which place and what was clicked. It's still non > reproducible here yet. And I've already put a try/catch in CellAt in this > place to try to TestFlight.Log something and then re-throw the exception but > nothing was sent. > > You cannot catch native signals (_sigtramp and the like) with managed > try-catch handlers, once you get a native signal something very bad has > occurred in the process, and the only sane thing MonoTouch can do is to > crash. Unfortunately post-mortem debugging of native crashes is quite hard, > usually even close to impossible without more information due to the fact > that the crash ifself may not be close to the actual bug (you can have a bug > that corrupts memory, but not crash until a minute later - at that point it's > impossible to know what happened a minute earlier). > > There are two main methods I use to track down these issues: > * Add lots of logging. Log several times for each method you think is > relevant. This obviously only helps when you're crashing inside your own code. > * Create a smaller test case. I comment out / remove code until the crash > goes away. Then I re-add code until the crash returns, and try to remove a > different part of the code. Repeat until you've reached a small test case, in > which you've either figured out what's going on, or if you still don't > understand it ask someone else (us for instance, in mailing lists / bugzilla). > > I hope this helps, > Rolf > > > Thanks, > > Karl > (not hacket yet, maybe never) > > _______________________________________________ > MonoTouch mailing list > [email protected] > http://lists.ximian.com/mailman/listinfo/monotouch > >
_______________________________________________ MonoTouch mailing list [email protected] http://lists.ximian.com/mailman/listinfo/monotouch
