Recurring EXC_BAD_ACCESS KERN_INVALID_ADDRESS crash in _pthread_testcancel while app in the background

Bug
1

Hello, we are frequently getting a crash in our app when it’s running in the background playing audio.

The crash is a EXC_BAD_ACCESS KERN_INVALID_ADDRESS in _pthread_testcancel, it’s always in this place on all occasions.

From Crashlytics we can see that the user’s phone at the time has low free RAM memory (2%-3%), but not from us, we are using only around 40-60MB of RAM when it crashes.
Maybe the OS is trying to free up some resources of the app and it causes a crash.
We are using the latest MOE 1.2 version.
The crashes all happened on iOS 10.0.2, 10.1.1, 10.0.1, on iPhone 5s, and iPhone 6.

The crashing thread always has this stack trace:

EXC_BAD_ACCESS KERN_INVALID_ADDRESS 0x0000000000000014

0  libsystem_pthread.dylib        0x18ee3ffc0 _pthread_testcancel + 40
1  libsystem_pthread.dylib        0x18ee3f9d0 _pthread_cond_wait + 656
2  libsystem_pthread.dylib        0x18ee3f9d0 _pthread_cond_wait + 656
3  MOE                            0x1029d090c art::ConditionVariable::TimedWait(art::Thread*, long long, int) + 120
4  MOE                            0x1029a8120 art::Monitor::Wait(art::Thread*, long long, int, bool, art::ThreadState) + 512
5  MOE                            0x104832a14 (Missing)

We have full crash logs if needed.

What can we do to solve this?

2

Dear Alex,

we will need the full crashlogs to look at this. The more crash logs, the better (so we can see if there is a variation in them.). Can you confirm, that you are using MOE 1.2.5? 1.2.5 added a fix in the arm64 code generator.

Best Regards,
Gergely

3

Yes it’s 1.2.5

See is the full crash log I have:

Muvix 01-12-2016, 8-32 PM.crash.zip (16.3 KB)

If I get more I will post them too.

4

From the attached crash log it looks like the “server time timer” thread is crashed. Is this a thread that you created? What does it do? More specifically: what does it do while your app is in the background? Would it be possible to stop it when your app goes into the background?

About the crash: we symbolicated the crash log, and checked the source of pthread. From the source it looks like pthread_testcancel() tries to aquire an internal pthread lock, from pthread_self(). However, pthread_self() returned NULL for some weird reason. pthread_self() actually returns the contents of a thread local storage slot and it shouldn’t be null in any thread created by pthread.

We don’t know yet, how this could even happen. How frequently does this happen?
Were you able to reproduce this issue locally, or it only happened in the wild?

5

This thread is responsible for synchronizing the current time from an NTP server, which we need to be relatively accurate for our needs. It’s activity is very small, and the code is slso very small.
It is not this specific thread that crashes every time, sometimes it’s different threads.
We have several crashes with this error in Crashlytics.
I’m not sure how to send it to you.
According to crashlytics the device had only 2-3% ava

6

2-3% available RAM left at the time of the crash.
And in every case it’s the same stack trace in the thread that crashes.
So my guess is that something gets realeased in pthread but still being used later…

7

Ok, this is an important information that it happens on other threads as well.

Is the stack trace of the crashing thread always exactly the same (including the addresses and the faulty memory address (0x14)) ?

8

Yes it is always the same

9

Hi,

Any progress on this guys?

Thanks.

10

Any help would be appreciated guys