Crash Analysis and Mitigation Strategies for JD Finance iOS App

In early 2020 the JD Finance mobile app saw rapid user growth, but its crash rate also rose to several per‑thousand, threatening user experience and brand reputation. The article first defines a crash as the CPU’s explicit response to an exception, describing how interrupts and exceptions differ across Intel and ARM architectures.

It then details three typical crash categories:

Wild pointers : accessing undefined memory addresses, often caused by uninitialized pointers in C or released objects in Objective‑C, leading to EXC_BAD_ACCESS.

Deadlocks : e.g., using dispatch_sync on the main queue, which blocks the main thread and triggers a crash.

Watchdog timeouts : the OS terminates the app if launch or response time exceeds a threshold, identified by error code 0x8badf00d.

Real‑world case studies from the JD Finance app illustrate these problems.

Case 1 – Wild pointer caused by MQTT long‑connection : The app’s background‑foreground switch triggered a crash in the open‑source MQTTClient library. The offending callback was:

- (void)stream:(NSStream *)sender handleEvent:(NSStreamEvent)eventCode

During debugging the team reproduced the issue by repeatedly toggling the app’s state. The crash occurred because the MQTTCFSocketDecoder object was released on a background thread while still referenced in the stream callback. The fix added a strong reference inside the callback:

- (void)stream:(NSStream *)sender handleEvent:(NSStreamEvent)eventCode {
MQTTCFSocketDecoder *strongDecoder = self;
(void)strongDecoder;
// other code…
}

After retaining the object, the crash disappeared.

Case 2 – Over‑release in multithreaded Lottie handling : Two threads (one for local cache, one for network) called handleCacheFilePath: simultaneously, each assigning manager.lottieData = zipData on a non‑atomic property. The underlying runtime function objc_setProperty_nonatomic performed:

void objc_setProperty_nonatomic(id self, SEL _cmd, id newValue, ptrdiff_t offset) {
reallySetProperty(self, _cmd, newValue, offset, false, false, false);
}

and the inline reallySetProperty released the old value without synchronization, causing a double release. The solution was to mark the property atomic or redesign it as a temporary variable.

Case 3 – Method‑call exception : The article explains how Objective‑C message sending works, how objc_msgSend looks up selectors, and how unimplemented selectors trigger unrecognized selector sent to instance . It shows dynamic method resolution and message forwarding examples:

+ (BOOL)resolveInstanceMethod:(SEL)sel {
if (sel == @selector(handleOpenPage:)) {
IMP imp = class_getMethodImplementation([self class], @selector(openNewPage:));
class_addMethod([self class], sel, imp, "v@:");
return YES;
}
return [super resolveInstanceMethod:sel];
}

and forwarding:

- (id)forwardingTargetForSelector:(SEL)aSelector {
if(aSelector == @selector(handleOpenPage:)) {
return _otherObject;
}
return [super forwardingTargetForSelector:aSelector];
}

and

- (void)forwardInvocation:(NSInvocation *)anInvocation {
if ([_otherObject respondsToSelector:[anInvocation selector]]) {
[anInvocation invokeWithTarget:_otherObject];
} else {
[super forwardInvocation:anInvocation];
}
}

The article then covers crash‑log analysis: extracting crash type, thread, stack trace, symbolication using dSYM files, and locating the offending code line. It recommends using Xcode Organizer, device logs, or APM platforms for collection.

Finally, it outlines a systematic crash‑mitigation workflow: forming a dedicated crash‑fix team, prioritizing crashes by frequency and impact, using link‑map or grep to map crashes to modules, establishing real‑time monitoring with thresholds, and enforcing coding standards and code reviews to prevent recurring issues.