iOS EXC_BAD_ACCESS Attempted to dereference garbage pointer TwilioPoco

Question

I am having difficulties figuring out this issue that I see on sentry and crashlytics. I'm not sure how to replicate the bug and the stacktrace is little cryptic to me. Does anyone have any idea?

OS Version: iOS 11.4.1 (15G77)
Report Version: 104

Exception Type: EXC_BAD_ACCESS (SIGBUS)
Exception Codes: BUS_NOOP at 0x0000000102cb2c30
Crashed Thread: 8

Application Specific Information:
Final state > onDisconnectedImpl >>  > pMethodNf > src/ActiveDispatcher.cpp >
Attempted to dereference garbage pointer 0x102cb2c30.

Thread 8 Crashed:
0   <unknown>                       0x102cb2c30         _ZTVNSt3__120__shared_ptr_emplaceIN5boost4asio20basic_waitable_timerINS_6chrono12steady_clockENS2_11wait_traitsIS5_EENS2_22waitable_timer_serviceIS5_S7_EEEENS_9allocatorISA_EEEE
1   TwilioChatClient                0x102a81588         rtd::TNTwilsockClient::onDisconnectedImpl(std::__1::pair<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::shared_ptr<rtd::TNTwilsockClient> > const&)
2   TwilioChatClient                0x102a9397c         TwilioPoco::ActiveRunnable<void, std::__1::pair<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::shared_ptr<rtd::TNTwilsockClient> >, rtd::TNTwilsockClient>::run()
3   TwilioChatClient                0x1027fb47c         TwilioPoco::ActiveDispatcher::run()
4   TwilioChatClient                0x1027f802c         TwilioPoco::ThreadImpl::runnableEntry(void*)
5   libsystem_pthread.dylib         0x3037d8220         <redacted>
6   libsystem_pthread.dylib         0x3037d8110         _pthread_start

Answer 1

My first attempt at answer wasn't nearly detailed enough to be helpful - my apologies. Let's try again.

Based on the App Specific info Attempted to dereference garbage pointer, and the fact that you're a few frames into an allocator, I believe that you are experiencing heap corruption. These kinds of crashes can be really hard to debug.

Heap corruption, which is a specific case of a memory corruption, can be hard to track down. The main reason is the source of the corruption is usually not captured at all by the stack trace. Typically, the crashes are just symptoms.

You cannot even be confident that the TwilioChatClient library is even responsible. It's totally possible, and common, for an unrelated system to just overwrite a bit of memory Twilio uses. What's worse, this could have happened much earlier in time before the now-invalid memory gets used.

What I generally recommend in these situations:

• Look for other crashes that look memory-corruption-related
• Try out Zombies in Instruments
• Try malloc scribble, or guardmalloc, two other good memory debugging tools

It's hard, and often even impossible, to reason about heap corruption. Replicating the bug can also be impossible, as memory corruption crashes are typically not deterministic.

So, just try to find and fix as many issues as you can. It's totally possible that one of them is responsible for a variety of crashes, one of which could be this one.

Answer 2

I had this same issue stemming from using incorrect types in NSLocalizedString.

static func errorCodeFormatter(_ errcode: Int) -> String {
   let formatter = NSLocalizedString("Error (%@)", comment: "comment")
   return String(format: formatter, errcode)
}

Calling this function will crash with the same error message. The solution was to change errCode to a String, or change the string param to @d

So either option below fixes this for me:

static func errorCodeFormatter(_ errcode: String) -> String {
   let formatter = NSLocalizedString("Error (%@)", comment: "comment")
   return String(format: formatter, errcode)
}

or alternatively:

static func errorCodeFormatter(_ errcode: Int) -> String {
   let formatter = NSLocalizedString("Error (%d)", comment: "comment")
   return String(format: formatter, errcode)
}