Crash in ARTOSReachability

[escfrya]

Seems like ARTOSReachability_Callback has referance to deallocated object.
ably version: 1.0.1

{code}
Crashed: com.apple.main-thread
EXC_BAD_ACCESS KERN_INVALID_ADDRESS 0x0000000000000010

0 Ably -[ARTOSReachability internalCallback:] + 80
1 Ably ARTOSReachability_Callback + 124
2 SystemConfiguration reachPerformAndUnlock + 580
3 CoreFoundation CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION + 24
4 CoreFoundation __CFRunLoopDoSources0 + 540
5 CoreFoundation __CFRunLoopRun + 744
6 CoreFoundation CFRunLoopRunSpecific + 424
7 GraphicsServices GSEventRunModal + 100
8 UIKit UIApplicationMain + 208
9 test AppDelegate.swift line 15
10 libdyld.dylib start + 4

{code}

[tcard]

@escfrya Thanks for the report! Is this happening always/often? If so, could you tell us how? Logs with ARTClientOptions.logLevel set to .Debug would be ideal.

[escfrya]

@tcard I can't reproduce this bug on my device.
Stacktrace from Crashlytics, and i see 18 crashes in dashboard (not so often).

[tcard]

I've added 8297ea4 (1.0) and bada06b (0.8). That should prevent a crash, but the underlying condition causing the crash is probably not fixed. We also can't reproduce this issue, so this requires further looking into.

@escfrya Could you tell us what you have at AppDelegate.swift, line 15?

[escfrya]

@tcard line 15 - class AppDelegate: UIResponder, UIApplicationDelegate {

[escfrya]

@tcard Unfortunately, crash reproduced in new app version(ably version 1.0.3)

Crashed: com.apple.main-thread
EXC_BAD_ACCESS KERN_INVALID_ADDRESS 0x0000000000000010

0	Ably	-[ARTOSReachability internalCallback:] + 84
1       Ably	ARTOSReachability_Callback + 144
2	SystemConfiguration	 reachPerformAndUnlock + 640
3	CoreFoundation	__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 24
4	CoreFoundation	__CFRunLoopDoSources0 + 524
5	CoreFoundation	__CFRunLoopRun + 804
6	CoreFoundation	CFRunLoopRunSpecific + 444
7	GraphicsServices	GSEventRunModal + 180
8	UIKit	-[UIApplication _run] + 684
9       UIKit   UIApplicationMain + 208
10	test	AppDelegate.swift line 15 main
11	libdispatch.dylib

[mattheworiordan]

Hi @escfrya. That's disappointing to hear. We're working on a release right now that will help us a) prevent crashes across the board and instead emit an error and fail, b) allow us to debug the issues in more detail by capturing the state and what has happened prior to the failure. I am sure @tcard will be in touch on Monday with details on that.

[mattheworiordan]

@tcard it seems this error is still happening according to our internal error reporting.

EXC_BAD_ACCESS
errorAttempted to dereference garbage pointer 0xd8716bec8.

See https://errors.ably.io/ably/ably-ios/issues/100893/ for the details.

@tcard this is reported in 1.0.3. @tcard do you think an upgrade to 1.0.4 may fix this, or is this issue unrelated to any fixes in 1.0.4?

[tcard]

@mattheworiordan I've been seeing those errors, but they have nothing to do with this. In fact, if you look at the stack trace (which for some reason Sentry thinks is invalid; we should migrate to the official Sentry library now that it's in Obj-C —anyway, it's visible as JSON if you expand the error on the top) there's a bunch of "" functions, so we don't know if it's Ably's fault at all.

[mattheworiordan]

so we don't know if it's Ably's fault at all.

Any ideas how we can isolate that in the future so we do know then?

[mattheworiordan]

@tcard additionally, could we modify the error sent to our exception tracker so that the errors are grouped? I believe the reference is what is preventing that. Perhaps look at the fingerprinting feature.

[tcard]

@escfrya Can you confirm this is still happening? We haven't had any other reports of this, and cannot reproduce ourselves.

[escfrya]

@tcard sorry, but i doesn't use Ably anymore

[mattheworiordan]

@escfrya sorry to hear that Igor. Mind if I ask why?

[escfrya]

@mattheworiordan i leaved project. The reason is not in Ably :)

[mattheworiordan]

Ok, that's a shame, thanks for the response @escfrya

[cdinarte]

@mattheworiordan This crash is still happening on the latest version 1.2.3, any ideia as to why it happens?

Crashed: io.ably.main
0  libsystem_pthread.dylib        0x1f8ab30cc pthread_mutex_lock$VARIANT$armv81 + 102
1  SystemConfiguration            0x1b28b5718 SCNetworkReachabilitySetCallback + 64
2  Ably                           0x100c2c3f8 -[ARTOSReachability listenForHost:callback:] + 60 (ARTOSReachability.m:60)
3  Ably                           0x100c432a4 -[ARTRealtimeInternal transitionSideEffects:] + 562 (ARTRealtime.m:562)
4  Ably                           0x100c41e2c -[ARTRealtimeInternal transition:withErrorInfo:] + 482 (ARTRealtime.m:482)
5  Ably                           0x100c1c8f0 -[ARTEventListener timeout] + 130 (ARTEventEmitter.m:130)
6  Ably                           0x100c20698 __artDispatchScheduled_block_invoke + 46 (ARTGCD.m:46)
7  libdispatch.dylib              0x1b2034cb0 _dispatch_block_async_invoke2 + 104
8  libdispatch.dylib              0x1b2052280 _dispatch_client_callout + 16
9  libdispatch.dylib              0x1b202abf8 _dispatch_continuation_pop$VARIANT$armv81 + 404
10 libdispatch.dylib              0x1b203b46c _dispatch_source_invoke$VARIANT$armv81 + 1252
11 libdispatch.dylib              0x1b202e3bc _dispatch_lane_serial_drain$VARIANT$armv81 + 260
12 libdispatch.dylib              0x1b202efdc _dispatch_lane_invoke$VARIANT$armv81 + 404
13 libdispatch.dylib              0x1b2038800 _dispatch_workloop_worker_thread + 692
14 libsystem_pthread.dylib        0x1f8ab65a4 _pthread_wqthread + 272
15 libsystem_pthread.dylib        0x1f8ab9874 start_wqthread + 8

[QuintinWillison]

Hi @cdinarte and thanks for letting us know. We'll take a look. Is there any further context you can give us in respect of how you got this?

[cdinarte]

@QuintinWillison we believe the bug is happening when returning to the app after it has been on the background for some time, but we're not sure.

[ricardopereira]

From the stacktrace, it seems it is waiting indefinitely for a lock. The lock occurs inside the SCNetworkReachabilitySetCallback which is a system method. Maybe the context is not valid anymore since the crash occurs after an event timeout.

[ricardopereira]

@QuintinWillison Probably, #1100 might fix this issue too.

[cdinarte]

Hey guys, this issue is not gone. It is still happening, can you please check it?

[maratal]

Looks like this crash has the same nature as the one that was fixed here #1453
So I'm closing this, feel free to re-open it if you'll experience it again.

[xinjiesg]

Hi team, the issue is still there. What I did are:

1. connect to ably
2. turn of wifi
3. turn on wifi
4. connect to ably when app appear
5. app crash
   I also notice that it happen every time for my friend, but only happen like 2 out of 10 times on my side.
   Can help to take a look again? Any idea/workaround to prevent app crash?

Thanks so much.

[QuintinWillison]

Thanks for getting in touch, @xinjiesg. 😁 I'm reopening this issue so that we can look at this again. Are you able to enable verbose logging from the Ably SDK as that might provide more information to us? Or, even, perhaps provide us with a crash report? (you can supply this to us by raising a support ticket, in order not to need to share potentially sensitive information here in the public domain)

[maratal]

Hey @xinjiesg Couldn't you try branch from #1565?

[xinjiesg]

Hey @xinjiesg Couldn't you try branch from #1565?

Hi @maratal, this brach solved our issue, and so far we did not see any crash again. thanks for the help.

[maratal]

@xinjiesg Glad to hear that! But couldn't you provide little bit more details about how you setup ably stack? I assume you re-create ARTRealtime object each time app becomes active, am I right? Do you call close on old instance? A bit of your setup code would be helpful, thanks!

[xinjiesg]

Hi Marat, I did something like this: Step 1: declare object private var ably: ARTRealtime? Step 2: call connection func in viewDidAppear override func viewDidAppear(_ animated: Bool) {  super.viewDidAppear(animated)  connectAbly() } Step 3: do connection private func connectAbly() {  ably = ARTRealtime(options: options)  ably?.connection.on { stateChange in  ...  } } If it is the case, should I check if ably == nil in viewDidAppear, before call connection?

[maratal]

I would suggest to have some wrapper around ARTRealtime and put there all your communication with your server. So your view controllers were aware only about ready to use objects that you received from the server and not knowing about how those objects were received. See AblyPush in the Examples folder for the sample of such wrapper object.

[maratal]

Hi @xinjiesg, sorry for delay, but we decided to take different approach. Would you mind to try branch from #1565 again? Thanks in advance.

[xinjiesg]

Hi @maratal ok, I will try it. Thanks for the update

[deanna-lad]

Closing this issue because the work is being tracked in another issue #1380