2

My code looks like this:

CGRect screenRect = [[UIScreen mainScreen] bounds];
SomeView *infoView;
if(screenRect.size.height != 568.0){
    // iPhone 5/5s users crash in the next line
    infoView = [[[NSBundle mainBundle] loadNibNamed:@"SomeViews" owner:self options:nil] objectAtIndex:1];  
}else{
    infoView = [[[NSBundle mainBundle] loadNibNamed:@"SomeViews" owner:self options:nil] objectAtIndex:0]
}

However, I get some crash reports from Crashlytics for iPhone 5/5s users as comment in the above code.

I am surprising that the height is NOT 568 for 5/5s since my app only supports Portrait orientation. I have hundreds of active users and only 12 crashes happened on 4 users.

And even if a iPhone 5/5s device load the wrong nib(for 3.5inch screen), it should not cause crash. (I just tested.)

http://crashes.to/s/1ddc169b801

Crashlytics also shown me that 90% of the crashes are on jailbreak devices, which makes me wonder that if jailbreak devices can change this value in any way?

Fatal Exception: NSInvalidArgumentException
-[UIDeviceRGBColor superview]: unrecognized selector sent to instance 0x14732db0

0
CoreFoundation  
__exceptionPreprocess + 130
1
libobjc.A.dylib 
objc_exception_throw + 38
2
CoreFoundation  
-[NSObject(NSObject) doesNotRecognizeSelector:] + 202

...

22
UIKit   
-[NSBundle(UINSBundleAdditions) loadNibNamed:owner:options:] + 138
23
Banck   
BKAddRecordPagingViewController.m line 244 // line 244 is loadNibNamed
-[BKAddRecordPagingViewController viewDidLoad]

The crash report link shows the reason but I can't figure out why since I use only built-in UILabel, UIImageView, UITextView in the nib file.

Can anyone give me some advice to better check and if using 4 inch screen on jailbreak devices? The second question is that what caused the crash inside loadNibNamed?

benck
  • 2,034
  • 1
  • 22
  • 31
  • Is it possible that the nature of your app is such that it appeals to the same type of user that prefers to jailbreak their phones? It's hard to imagine that jailbreaking is what's causing this crash. – Nate Feb 25 '14 at 05:09
  • I don't think so. Only less than 10% of other crashes are from jailbreak phones. – benck Feb 25 '14 at 18:48
  • There are a few more crashes today, and all of them are from jailbreak phones. http://crashes.to/s/1ddc169b801 – benck Feb 25 '14 at 18:49
  • I am also getting these crash reports, although mine don't even tell me which of my controllers are causing the issue. I have a few that load xib's. 1 app is showing 100% jailbroken, another is showing 33% jailbroken. – Darren Feb 26 '14 at 10:49
  • I only have it from 24 users out of 40k so not too worried, but i'd love to know the reason, especially as it seems to also happen to none JB devices (Unless they maybe have a way to fool Crashlytics into thinking they are not JB). – Darren Feb 26 '14 at 10:52
  • Good to know that it's not only me having this issue. – benck Feb 27 '14 at 06:21
  • I think I'll start a bounty on this to get a bit more attention. Even though it's affecting less than 0.5% of my users I'd love to find a workaround. I only load xib's for table cells. – Darren Mar 05 '14 at 22:48
  • I wonder if it's a zombie object? I don't know how else an instance of UIDeviceRGBColor would be sent `superview`. So perhaps something on Jailbroken phones is altering nib loading? – nielsbot Mar 12 '14 at 18:08
  • My guess is a zombie object. Look for bugs in `initWithCoder` or `awakeFromNib`. – Sulthan Mar 12 '14 at 19:18

3 Answers3

2

I suspect the Cydia Tweak "Eclipse" has an overrelease bug. (Eclipse.dylib is listed in your crash trace)

An instance of UIView from your NIB is being released, and the memory reused for a UIDeviceRGBColor instance.

See if you can repro with the Cydia Eclipse add on? You could trace your allocations with Instruments.

nielsbot
  • 15,922
  • 4
  • 48
  • 73
  • I sent an e-mail to the listed author of Eclipse.. I'll let you know if he responds. I couldn't find the source code for it anywhere. – nielsbot Mar 13 '14 at 01:04
  • maybe you could refuse to load if the library Eclipse.dylib is loaded too – nielsbot Mar 13 '14 at 01:05
  • That's an interesting thought. Where would we even start to detect it? Could maybe just throw a message up. – Darren Mar 13 '14 at 10:16
  • If you find out the name of a symbol unique to Eclipse, you could call `dlsym` and see if it returns a non-zero result. (To find the symbols on Eclipse, download the dylib and run the `nm` tool on it) – nielsbot Mar 13 '14 at 18:26
  • That's correct, I can confirm it's caused by this: http://www.iphonehacks.com/2014/01/eclipse-ios-7-tweak-brings-night-theme.html I saw this crash in HockeyApp a couple of months ago and I was just in touch with a user that was experiencing these crashes. – Javier Soto Mar 19 '14 at 19:43
0

Use UIScreen mainScreen

CGRect screenBounds = [[UIScreen mainScreen] bounds];
if (screenBounds.size.height == 568) {
// code for 4-inch screen
} else {
// code for 3.5-inch screen
}

I think it does not have anything to do with jb.

Alessandro Vendruscolo
  • 14,493
  • 4
  • 32
  • 41
ares777
  • 3,590
  • 1
  • 22
  • 23
  • 2
    I don't know if it's related, but in your code you're comparing floats (height == 568.0). You should never do that: use integers in both cases ((int)screenBounds.size.height == 568) – ItalyPaleAle Mar 05 '14 at 23:38
0

Suggestion 1:

  • Do not equate the float with 568.0f. Just check if it is bigger than 567 and less than 1024

Suggestion 2:

Anindya Sengupta
  • 2,539
  • 2
  • 21
  • 27
  • I don't think the if statement is the cause of the crash. I am having the same crash but I only load .xib's for table cells. – Darren Mar 12 '14 at 15:27