Capture 1.8.53 crash on SktCaptureProtocol::Deinitialize()

[yliu342]

Hi @cyrille-socket Since upgrading to the 1.8.53 SDK we've seen some crash on SktCaptureProtocol::Deinitialize(). I can't reproduce locally but I do see crash reports coming from firebase. Here is the crash log. It seems some memory issue with that method.

crash_info_entry_0 | abort() called
crash_info_entry_1 | yourApp(295,0x16df5b000) malloc: *** error for object 0x1037459b0: pointer being freed was not allocated

Crashed: CaptureServiceQueue (QOS: UNSPECIFIED)
0  libsystem_kernel.dylib         0x9fbc __pthread_kill + 8
1  libsystem_pthread.dylib        0x5680 pthread_kill + 268
2  libsystem_c.dylib              0x75b90 abort + 180
3  libsystem_malloc.dylib         0x26200 malloc_vreport + 908
4  libsystem_malloc.dylib         0x263e4 malloc_report + 64
5  libsystem_malloc.dylib         0x6060 find_zone_and_free + 308
6  CaptureSDK                     0x33d7c SktCaptureProtocol::Deinitialize() + 40
7  CaptureSDK                     0x739a0 SktCaptureClose(void*) + 108
8  CaptureSDK                     0x30828 __57-[SKTCaptureServiceDirect closeHandle:completionHandler:]_block_invoke + 160
9  Foundation                     0x47188 __NSBLOCKOPERATION_IS_CALLING_OUT_TO_A_BLOCK__ + 24
10 Foundation                     0x7860c -[NSBlockOperation main] + 104
11 Foundation                     0x75e94 __NSOPERATION_IS_INVOKING_MAIN__ + 16
12 Foundation                     0x74f84 -[NSOperation start] + 648
13 Foundation                     0x77a9c __NSOPERATIONQUEUE_IS_STARTING_AN_OPERATION__ + 16
14 Foundation                     0x77808 __NSOQSchedule_f + 172
15 libdispatch.dylib              0x13250 _dispatch_block_async_invoke2 + 148
16 libdispatch.dylib              0x4300 _dispatch_client_callout + 20
17 libdispatch.dylib              0x77b8 _dispatch_continuation_pop + 600
18 libdispatch.dylib              0x6e68 _dispatch_async_redirect_invoke + 732
19 libdispatch.dylib              0x15be4 _dispatch_root_queue_drain + 392
20 libdispatch.dylib              0x163ec _dispatch_worker_thread2 + 156
21 libsystem_pthread.dylib        0x1928 _pthread_wqthread + 228
22 libsystem_pthread.dylib        0x1a04 start_wqthread + 8

[cyrille-socket]

Hi @yliu342

ok I'll look into it. Do you have any code in your app that calls the close capture instance?

We advise that developers shouldn't close the SDK. It handles by itself and responds to the lifecycle of the app.

[yliu342]

No we don’t call close anywhere in our code. 

[cyrille-socket]

This crash has been fixed in the last release 1.8.57 on our private repository.

[yliu342]

Just saw you pushed a new version of the SDK which fixed this issue. But I just did another check of our code and noticed we do indeed make a call to close. But definitely not at the time of this crash happened.

We have a toggle to control the use of physical scanner. If user toggle it on, we will start the Socket SDK. If the user toggle from on -> off we will call close. It is rare user turn on and off the toggle.

[cyrille-socket]

Yes the new version 1.8.57 has been released with the fix. Either the close is triggered by your code or by the SDK it self, it's solved.

[mortenbekditlevsen]

Hi @yliu342

ok I'll look into it. Do you have any code in your app that calls the close capture instance?

We advise that developers shouldn't close the SDK. It handles by itself and responds to the lifecycle of the app.

Hi @cyrille-socket ,

Do you document how and when the SDK responds to lifecycle events? We have two apps that both use a scanner, and it is critical that the apps disconnect from the scanner upon backgrounding, so that the scanner is available for use in the app that is next foregrounded.

It would be great if the lifecycle management was documented thoroughly and the recommendation about not calling close was followed up by a description of what happens if you do not follow the recommendation.