A problem with the running crash of the package real machine

A problem with the running crash of the package real machine

1. Problem description

1.1. Operating environment

• Simulator version: iPhone6 ​​&& 8.4||9.3
• Real machine version: iPhone6p && 8.4
• Signed certificate: enterprise issued certificate, personal development certificate

1.2. Background

After the APP function is basically completed, because the iOS version will be used to demonstrate to the leaders, I hurriedly packaged it to the needs in the morning.

1.3. Problem

Because there was a problem that the build package failed to install the 5c mobile phone two days ago (architecture does not match, /(ㄒoㄒ)/~~), so honestly packaged with the enterprise certificate archive, packaged and uploaded to the Dandelion website, and then used Test the mobile phone 6p scan installation.

After the installation was successful, I clicked all the functions, but at the end I suddenly found that a function to open a webpage reported a 404 error, and several open webpage functions on another page simply crashed and crashed! After a while in my mind, I quickly took the URL to the browser and opened it, which is normal. Then use the simulator to run the breakpoint, and found that it is also normal. It is normal to use a personal developer certificate to debug on a real machine! !

2. Solution

2.1. Ideas

Because it is normal to run in the simulator and in the debugging mode of the real machine, I began to suspect that the problem lies in the enterprise certificate or archive packaging.

So I tried another enterprise certificate archive package, and found that the same problem still exists. The problem does not exist with the use of enterprise certificate build packaging. So I feel that the problem still lies in the archive packaging.

I checked the crash log of the phone in Xcode and found a Terminating app due to uncaught exception'NSInvalidArgumentException', reason: ' * setObjectForKey: object cannot be nil (key: nsrsbh) error message.

And this nsrsbh information only has value when the APP is logged in. However, the function that has the crash problem can actually be accessed directly without the need to log in.

So the final problem is located in the following piece of code:

        GDWebURLParseType parseType;
        if ([extraInfo[@"parserType"] isEqualToString:@"tgc"]) {
            parseType = GDWebURLParseTypeTGC;
        } else if ([extraInfo[@"parserType"] isEqualToString:@"cl"]) {
            parseType = GDWebURLParseTypeCL;
        } else if ([extraInfo[@"parserType"] isEqualToString:@"lt"]) {
            parseType = GDWebURLParseTypeLT;
        }
        webUrl = [GDUtil parseWebURL:webUrl parseType:parseType];

The parseType variable is an enumerated variable,

typedef NS_ENUM(NSUInteger, GDWebURLParseType) {
    GDWebURLParseTypeLT,
    GDWebURLParseTypeCL,
    GDWebURLParseTypeTGC
};

The +GDUtil parseWebURL:parseType: method will assemble the url according to the different parseType. When the parseType is GDWebURLParseTypeLT, the nsrsbh field assignment in the above crash information will be used.

From this point of view, the problem lies in the default value of parseType, which is a random number in the simulator/debug mode, while it is 0 on the real archive machine, so the code logic that needs to be logged in is entered in the unlogged state. , Which leads to a crash.

2.2. Conclusion

Now that the problem has been located, it is easy to solve it. You only need to assign an initial value to the enumeration type.

GDWebURLParseType parseType = NSIntegerMax;

After the modification, re-archive, package, install and run, everything is OK.

3. Reason

The reason for this problem has not been investigated in depth, but from the normal grammatical rules, the initial value of the globally defined enumeration type is 0, which is GDWebURLParseTypeLT in this case. Therefore, you must maintain good coding habits when coding, and you must do less variable initialization.