Swift runtime failure: arithmetic overflow MPIHasher.hashString(_:)

[AnilVarghese]

Since we upgraded to v8.17.0, seeing a crash Swift runtime failure: arithmetic overflow from MPIHasher.hashString(_:). Below you can find the full stack trace. We traced down the crash to MPIHasher line 33

var hash: Int32 = 0
for byte in dataToHash {
    hash = ((hash << 5) &- hash) + Int32(byte);  // <= crashes here
 }

This would likely due to the resulting hash value exceeds the range of Int32. Using Int64 might fix it. Could you please fix it Thank you

Stack trace

0  mParticle_Apple_SDK +0x9a898 Swift runtime failure: arithmetic overflow (<compiler-generated>)
1  mParticle_Apple_SDK +0x99c54 static MPIHasher.hashString(_:) (<compiler-generated>)
2  mParticle_Apple_SDK +0x54688 -[MPKitConfiguration initWithDictionary:] (MPKitConfiguration.mm:29:29)
3  mParticle_Apple_SDK +0x57d48 -[MPKitContainer initializeKits] (MPKitContainer.mm:294:48)
4  mParticle_Apple_SDK +0x259bc __132-[MPBackendController startWithKey:secret:firstRun:installationType:proxyAppDelegate:startKitsAsync:consentState:completionHandler:]_block_invoke (MPBackendController.m:1511:13)
5  libdispatch.dylib +0x231c    __dispatch_call_block_and_release
6  libdispatch.dylib +0x3ea8    __dispatch_client_callout
7  libdispatch.dylib +0x126a0   __dispatch_main_queue_drain
8  libdispatch.dylib +0x122f0   __dispatch_main_queue_callback_4CF
9  CoreFoundation +0x98c24      ___CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__
10 CoreFoundation +0x7a55c      ___CFRunLoopRun
11 CoreFoundation +0x7f3e8      _CFRunLoopRunSpecific
12 GraphicsServices +0x1358     _GSEventRunModal
13 UIKitCore +0x39cf54          -[UIApplication _run]
14 UIKitCore +0x39cbb8          _UIApplicationMain
15 Glover +0x97fc               main (main.swift:12:1)
16 dyld +0x15de8                start

[maurovc]

hey @einsteinx2 I believe https://github.com/mParticle/mparticle-apple-sdk/pull/246 and https://github.com/mParticle/mparticle-apple-sdk/releases/tag/v8.18.0 fix this issue right?

Can you please confirm so we can track this on our end?

Thanks!

[einsteinx2]

@maurovc apologies for the late reply. Yes that release does resolve the issue. The overflow is actually intentional, it's the crash that wasn't. That's been fixed by using the overflow addition operator.