If it can be reproduced, then finding the problem shouldn’t be that hard get 
your CEOs devices and connect them to your mac and run the app in debug mode 
and make it crash. Then look at the stacktrace and you are likely to see where 
it is originating from. If not put a lot of debug messages in the code to try 
and find the problem that way. 

If your CEO can make it crash but you can’t he is probably doing something you 
aren’t or in a different order.

In short you need to get your CEOs devices and start to debug for real.

Richard.

From: Dean Cleaver 
Sent: Saturday, October 13, 2012 6:42 AM
To: Craig Dunn 
Cc: [email protected] ; James Darbyshire 
Subject: Re: [MonoTouch] Any idea what this could be?

It seems to be easily reproducible on given devices and iOSs – but not always. 
iOS6 seems fine on all 3 devices (4S, 4 and iPod Touch) I have here, but it 
crashes on my CEOs iPad 2 with iOS6 and his 4S with iOS5. I need to grab them 
off him to see if I can find a pattern, but he seems to get consistent crashes 
regardless.

 

I could do a diff, but there’s been so many check-ins in the past week, and the 
project is about 200 files, so to check each one, see what’s changed etc could 
be a mammoth task. Nothing had changed in the area I’m seeing problems in 
though – that I already checked.

 

Dino

 

From: Craig Dunn [mailto:[email protected]] 
Sent: Friday, October 12, 2012 20:38
To: Dean Cleaver
Cc: James Darbyshire; [email protected]
Subject: Re: [MonoTouch] Any idea what this could be?

 

Yeah, actually deploying a MT5.2-based app might not be the solution, just 
wondering if it resolves the issue and therefore helps narrow it down to 
something in MT or something in the app?

 

Another thing that I'm not sure you've mentioned is whether it is easily, 
reliably reproducible - or just random? If random, is it still guaranteed to 
happen within a certain period (ie. always happens within 5 minutes of usage) 
or something like that? You did say that sometimes it fails differently (ie. 
disables home button?) - is it always the same error message with the same 
'breaking' behaviour, or was that a specific combination of code that was 
repeatable? since the errors are around foreground behaviour, i 

 

As you said, it feels like a needle in a haystack. When all else fails, I 
usually end up doing a source-control diff to my last-known-good version and 
undoing everything bit-by-bit. Even that is very difficult if you can't 
easily/reliably reproduce in the first place, cause you don't know when it's 
fixed :)

 

If you _can_ easily/reliably reproduce, the best bet is to gradually rip out 
code until you have the smallest breaking example and submit that to bugzilla 
for the devs to investigate. But that only works if it is reproducible to start 
with :-\

wish i could give some more concrete advice, but as you say it's a very vague 
situation to start with. 

 

cd

 

p.s. random question: I presume that WillEnterForeground code is in your 
AppDelegate? are you also creating 
NSNotificationCenter.DefaultCenter.AddObserver() listeners for 
UIApplication.WillEnterForegroundNotification anywhere in your app? long shot i 
know...

 

On Sat, Oct 13, 2012 at 12:11 PM, Dean Cleaver 
<[email protected]> wrote:

Craig,

 

I went from version 5.2.12. I didn’t know 6.0.4 was out, until I re-started 
MonoDevelop after installing 5.2.12 again, but I see it only changes a compiler 
setting for something specific.

 

Am going to recompile in 5.2.12 and see if the CEO has the same problems. If 
so, it probably is something I did in code, but what I have no idea. The 
exception reports are all extremely vague.

 

Looks like going back to 5.2.12 is not an option as I still only have SDK 6 as 
a choice, and it means all the orientation stuff is broken. So unless I buy 
another Mac with Lion on it and go back to XCode 4.4 I’m not sure how I can get 
around that.

 

Dino

 

From: Craig Dunn [mailto:[email protected]] 
Sent: Friday, October 12, 2012 19:44
To: Dean Cleaver
Cc: James Darbyshire; [email protected]


Subject: Re: [MonoTouch] Any idea what this could be?

 

from what version did you move _to_ 6.0.3? perhaps the changelog between the 
two releases might point at something that's been updated to give you a clue?

 

also, 6.0.4 has been released

http://docs.xamarin.com/ios/releases/MonoTouch_6/MonoTouch_6.0#MonoTouch_6.0.4

-- you might already have been prompted to download that? might be worth 
trying? alternatively, does downgrading back to the previous MT version you had 
fix the problem?

 

cd

 

On Sat, Oct 13, 2012 at 11:40 AM, Dean Cleaver 
<[email protected]> wrote:

James,

 

I did share the code. That’s it:

 

public override void WillEnterForeground(UIApplication application){            
        try                    {                                         
//ThreadPool.QueueUserWorkItem(this.EnterForeground);                    }      
              catch (Exception ex)                    {                         
                Application.SendError(ex);                    }} 

I can’t publish my entire app code in here. But why am I getting exceptions 
that simply crash my app in a method that I have no real code in? Even if I 
comment out the entire “WillEnterForeground” I still get explosions that just 
kill the app completely. 

 

It will not break in code – always just blows up. Never blew up before, just 
after I made the mistake of upgrading to MonoTouch 6.0.3. This code has been 
working for over 12 months, and now I’m in deep shit where I can’t publish a 
new version because I cannot get any help on some severe crashes.

 

Hell – I’ve even got one crash on an iPad where it actually manages to disable 
the Home button until you reboot the device – any ideas what API I might be 
using incorrectly to achieve that?

 

Dino

 

From: James Darbyshire [mailto:[email protected]] 
Sent: Friday, October 12, 2012 19:35
To: Dean Cleaver
Cc: [email protected]
Subject: Re: [MonoTouch] Any idea what this could be?

 

To be blunt, we can't help without having code to look through. 

 

MonoTouch doesn't just add method calls, and throw exceptions on its own. 

 

My guess is that your problem is probably an incorrect use of an API or object 
somewhere. 

 

iOS application development is a lot more accessible now, thanks to MT, but if 
you don't do the basics, just as with ObjC or PhoneGap (et. al.) your 
foundations will be shaky. 

 

Share the code, or at least somewhere we can reproduce the problem, and we can 
help you diagnose the problem. 

Regards,

 

James


On 13/10/2012, at 11:23 AM, Dean Cleaver <[email protected]> 
wrote:

  Anyone able to help before I ditch MonoTouch and try something that works? We 
are seriously in a position where we cannot release code because of this 
problem, and the CEO is discussing ditching MonoTouch completely because we 
can’t rely on it to work.

   

  Dino

   

  From: Dean Cleaver 
  Sent: Friday, October 12, 2012 17:16
  To: Dean Cleaver; [email protected]
  Subject: RE: Any idea what this could be?

   

  It’s now seemingly not Linea – just random:

   

  MonoTouch.Foundation.MonoTouchException: Objective-C exception thrown. Name: 
NSInvalidArgumentException Reason: -[OS_dispatch_semaphore 
UIApplicationWillEnterForeground:]: unrecognized selector sent to instance 
0x81b27e0
  at (wrapper managed-to-native) 
MonoTouch.UIKit.UIApplication:UIApplicationMain (int,string[],intptr,intptr)
  at MonoTouch.UIKit.UIApplication.Main (System.String[] args, System.String 
principalClassName, System.String delegateClassName) [0x0004c] in 
/Developer/MonoTouch/Source/monotouch/src/UIKit/UIApplication.cs:38 
  at KleverLogic.FlashValet.iPhone.Valet.Application.Main (System.String[] 
args) [0x00048] in 
/xsl-home/kleverlogic/FlashValet/Mobile/iPhone/Valet/Main.cs:40

   

  And here’s my WillEnterForeground:

   

public override void WillEnterForeground(UIApplication application){            
        try                    {                                         
//ThreadPool.QueueUserWorkItem(this.EnterForeground);                    }      
              catch (Exception ex)                    {                         
                Application.SendError(ex);                    }} 

  Yeah – basically empty, yet it still crashes in the 
UIApplicationWillEnterForeground – any ideas?

   

  Dino

   

  From: [email protected] 
[mailto:[email protected]] On Behalf Of Dean Cleaver
  Sent: Thursday, October 11, 2012 15:00
  To: [email protected]
  Subject: [MonoTouch] Any idea what this could be?

   

  I got this error report recently:

   

  MonoTouch.Foundation.MonoTouchException: Objective-C exception thrown. Name: 
NSInvalidArgumentException Reason: -[Linea UIApplicationDidEnterBackground:]: 
unrecognized selector sent to instance 0x21a2a80
  at MonoTouch.UIKit.UIApplication.Main (System.String[] args, System.String 
principalClassName, System.String delegateClassName) [0x0004c] in 
/Developer/MonoTouch/Source/monotouch/src/UIKit/UIApplication.cs:38 
  at KleverLogic.FlashValet.iPhone.Valet.Application.Main (System.String[] 
args) [0x00027] in 
/xsl-home/kleverlogic/FlashValet/Mobile/iPhone/Valet/Main.cs:40

   

  I’m intrigued by the “Reason: -[Linea UIApplicationDidEnterBackground:]” 
because I make no calls to the linea in this, so wondered if there was even 
anything I could do?

   

  Dino


_______________________________________________
MonoTouch mailing list
[email protected]
http://lists.ximian.com/mailman/listinfo/monotouch

 

 



--------------------------------------------------------------------------------
_______________________________________________
MonoTouch mailing list
[email protected]
http://lists.ximian.com/mailman/listinfo/monotouch
_______________________________________________
MonoTouch mailing list
[email protected]
http://lists.ximian.com/mailman/listinfo/monotouch

Reply via email to