Possible crash when loadNibNamed on jailbreak devices [UIDeviceRGBColor superview]: unrecognized selector

Question

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?

Liquidize

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. – Illusionary

I don't think so. Only less than 10% of other crashes are from jailbreak phones. – Liquidize

There are a few more crashes today, and all of them are from jailbreak phones. crashes.to/s/1ddc169b801 – Liquidize

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. – Brinson

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). – Brinson

Good to know that it's not only me having this issue. – Liquidize

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. – Brinson

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? – Schottische

My guess is a zombie object. Look for bugs in initWithCoder or awakeFromNib. – Tymon

Answer 1

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.

Schottische

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. – Schottische

maybe you could refuse to load if the library Eclipse.dylib is loaded too – Schottische

That's an interesting thought. Where would we even start to detect it? Could maybe just throw a message up. – Brinson

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) – Schottische

That's correct, I can confirm it's caused by this: iphonehacks.com/2014/01/… 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. – Neither

Answer 2

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.

Marbling

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) – Sulphurbottom

Answer 3

Suggestion 1:

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

Suggestion 2:

• This codebase has a very direct approach to detect various iOS devices. -- https://github.com/froztbytes/UIDeviceHardware

Polly

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. – Brinson