Urgent: Crash issue while performing lock or unlock operation

[pinalpsspl]

Please find the stack trace which could be useful in identifying the root cause of the crash. we do not have any further information apart from this crash log.

However, we know that this crash happened due to a lock or unlock operation. Please let us know if you need more information.

Crash Log:
Fatal Exception: NSInvalidArgumentException
0 CoreFoundation 0x83f20 exceptionPreprocess
1 libobjc.A.dylib 0x172b8 objc_exception_throw
2 Foundation 0xfa83c +[NSObject(NSObject) load]
3 App 0x611aac +[TTHandleResponse getLockDataModel:] + 1143 (TTHandleResponse.m:1143)
4 App 0x658bd0 -[TTLockModel setLockData:] + 23 (TTLockModel.m:23)
5 App 0x658b74 +[TTLockModel modelWithLockData:] + 16 (TTLockModel.m:16)
6 App 0x600554 -[TTLockApiManager controlLockWithControlAction:lockData:success:failure:] + 300 (TTLockApiManager.m:300)
7 App 0x628700 +[TTLock controlLockWithControlAction:lockData:success:failure:] + 364 (TTLock.m:364)

[ttlock]

From the crash log, it appears that there is an issue with "lockdata".
Is this breakdown happening every time or just by chance ?
If every time ,please send us the lockData.
If by chance, what is the probability of it happening? Let's try to reproduce it.

[pinalpsspl]

@ttlock

Thank you for looking into this.

From our side, we expect that the SDK should handle invalid or corrupted lockData gracefully without causing the app to crash. Instead of the crash, the SDK should return a TTError, which we can then manage within the app.

This ensures that any issues with the lockData don't lead to an unexpected termination of the app.

[ttlock]

We have done some processing on "lockData" , but we cannot guarantee that anything transmitted will not crash because we do not know what will be transmitted from outside.

[pinalpsspl]

Thank you for your response. I understand the challenges associated with processing "lockData."

However, I would like to emphasize the importance of ensuring stability, especially in scenarios where users might have limited or no internet access, such as in remote regions.

To mitigate potential crashes caused by invalid lock data, could you consider providing a validation function to check the integrity of the lock data before processing?

Alternatively, implementing error handling during operations would help ensure that the app can gracefully handle any issues without crashing.

This would significantly enhance the user experience, particularly for those relying on older lock data in low-connectivity areas.

I appreciate your attention to this matter and look forward to your thoughts.

[ttlock]

Can you send us the lockData that caused the crash? We will evaluate it

[pinalpsspl]

Unfortunately, we do not have the specific lockData that led to this crash.

[pinalpsspl]

@ttlock

any update?

[ttlock]

No, because we don't know how to optimize it.