Crash in [LPVarCache registerActionDefinition:ofKind:withArguments:andOptions:]

[anta-semenov]

Expected Behavior

Don't have crashes in the app

Actual Behavior

We see crashes on crashlytics

Steps to Reproduce the Problem

1. Unknown. This is a frequent crash reported to Crashlytics that we have not been able to reproduce.

Specifications

• Version: Leanplum-iOS-SDK 3.2.1
• Platform: iPhone, iOS 14, 15, 16
• Crash logs:

Crashed: com.facebook.react.LeanplumUtilsQueue
EXC_BAD_ACCESS KERN_INVALID_ADDRESS 0x000070ddfe89e060

0 libobjc.A.dylib 0x1f28 objc_msgSend + 8
1 CoreFoundation 0x2bf50 -[_NSDictionaryM setObject:forKeyedSubscript:] + 508
2 Leanplum 0x5bc58 -[LPVarCache registerActionDefinition:ofKind:withArguments:andOptions:] + 826 (LPVarCache.m:826)
3 Leanplum 0xff64 +[Leanplum defineAction:ofKind:withArguments:withOptions:withResponder:] + 1554 (Leanplum.m:1554)
4 Drops 0x33120 LeanplumUtils.defineTemplate(:) + 57 (LeanplumUtils.swift:57)
5 Drops 0x347bc @objc LeanplumUtils.defineTemplate(:) + 4302800828 (<compiler-generated>:4302800828)
6 CoreFoundation 0x21b24 invoking + 148
7 CoreFoundation 0x3f610 -[NSInvocation invoke] + 468
8 CoreFoundation 0x765fc -[NSInvocation invokeWithTarget:] + 80
9 Drops 0x3361e8 -[RCTModuleMethod invokeWithBridge:module:arguments:] + 587 (RCTModuleMethod.mm:587)
10 Drops 0x3387ec facebook::react::invokeInner(RCTBridge*, RCTModuleData*, unsigned int, folly::dynamic const&, int, (anonymous namespace)::SchedulingContext) + 183 (RCTNativeModule.mm:183)
11 Drops 0x33841c invocation function for block in facebook::react::RCTNativeModule::invoke(unsigned int, folly::dynamic&&, int) + 419 (Optional.h:419)
12 libdispatch.dylib 0x1e6c _dispatch_call_block_and_release + 32
13 libdispatch.dylib 0x3a30 _dispatch_client_callout + 20
14 libdispatch.dylib 0xb124 _dispatch_lane_serial_drain + 668
15 libdispatch.dylib 0xbc80 _dispatch_lane_invoke + 392
16 libdispatch.dylib 0x16500 _dispatch_workloop_worker_thread + 648
17 libsystem_pthread.dylib 0x10bc _pthread_wqthread + 288
18 libsystem_pthread.dylib 0xe5c start_wqthread + 8

Also I noticed that the code that is crashing is wrapped up with LP_TRY LP_END_TRY macros. Does it means that the exception is handled in some way and doesn't affect user?

Another weird thing is that LPVarCache.m:826 is just a last line in the method, which is just closing curly bracket. The previous line is actually assignment _actionDefinitions[name] = definition;

[nzagorchev]

Hi @anta-semenov, The LP_TRY macros are just a try/catch with custom exception handling logic:

#define LP_TRY @try {
#define LP_END_TRY }\
@catch (NSException *e) {\
[LPLogManager logInternalError:e]; }

It then depends on when the exception happened whether it will be rethrown.

Can you provide more information when is the LeanplumUtils.defineTemplate(:) called and what is the template defined?

Nikola

[anta-semenov]

We use react native. We call LeanplumUtils.defineTemplate(:) from react-native side after app start but before calling Leanplum.start

[nzagorchev]

It seems the exception is thrown if the name of the template passed is nil, which should not happen since it is validated in defineAction. The RN SDK does not have the defineAction method exposed, so I guess you call this natively directly from your Utils. Would it be possible to share more about your approach and the template values? You can open a support ticket if you don't want to share those here.

Note that the action definition logic is modified and no longer in the VarCache in newer versions which will be included in RN SDK soon.

[anta-semenov]

@nzagorchev here is the gist with our own RN binding for templates. There is a code for ios module and code for js function that uses it

[nzagorchev]

The code looks good. I have not been able to replicate it, and forcing a nil name (after the nil check), does produce the same stacktrace. I am unsure why this could happen especially when we are explicitly checking the name against null. In the newer versions, the action definitions are stored in an array, so this issue should not be happening.