Component used: gamesdk

Version used: agdk-libraries-2023.3.0.0.zip

Devices/Android versions reproduced on: Honor X9a 5G (Android 13), IQOO 12 Pro (Android 14), Realme C51s (Android 13)

We are getting a few user crash reports with the following callstacks:

Crashed: Thread: SIGABRT  0x0000000000000000
#00 pc 0x530f4 libc.so (BuildId: 465a4e4f3474259498fde6338e6bc02a)
#01 pc 0x530c4 libc.so (BuildId: 465a4e4f3474259498fde6338e6bc02a)
#02 pc 0x54f7c libc.so (BuildId: 465a4e4f3474259498fde6338e6bc02a)
#03 pc 0xc29dc libc.so (BuildId: 465a4e4f3474259498fde6338e6bc02a)
#04 pc 0xc2870 libc.so (BuildId: 465a4e4f3474259498fde6338e6bc02a)
#05 pc 0x19bf834 libAirwar.so (<name omitted> [__threading_support:367]) (BuildId: 96ebb8645e58a6a93394d2844ca09a10e3924d28)
#06 pc 0x196ce40 libAirwar.so (swappy::ChoreographerFilter::onSettingsChanged() [__mutex_base:91]) (BuildId: 96ebb8645e58a6a93394d2844ca09a10e3924d28)
#07 pc 0x196e0e0 libAirwar.so (swappy::Settings::notifyListeners() [functional:1884]) (BuildId: 96ebb8645e58a6a93394d2844ca09a10e3924d28)
#08 pc 0x1971bc0 libAirwar.so (Java_com_google_androidgamesdk_SwappyDisplayManager_nOnRefreshPeriodChanged [SwappyDisplayManager.cpp:158]) (BuildId: 96ebb8645e58a6a93394d2844ca09a10e3924d28)
#09 pc 0x351e30 libart.so (BuildId: 7ece79c15d80914c83e60c9e93ac1684)

and:

Crashed: Thread: SIGABRT  0x0000000000000000
#00 pc 0xa4924 libc.so (BuildId: 4425ba3ccfed552700ceb9be545d3599)
#01 pc 0xa48f4 libc.so (BuildId: 4425ba3ccfed552700ceb9be545d3599)
#02 pc 0xa6a84 libc.so (BuildId: 4425ba3ccfed552700ceb9be545d3599)
#03 pc 0x10dddc libc.so (BuildId: 4425ba3ccfed552700ceb9be545d3599)
#04 pc 0x10dc5c libc.so (BuildId: 4425ba3ccfed552700ceb9be545d3599)
#05 pc 0x19bf834 libAirwar.so (<name omitted> [__threading_support:367]) (BuildId: 96ebb8645e58a6a93394d2844ca09a10e3924d28)
#06 pc 0x196cfcc libAirwar.so (swappy::ChoreographerFilter::threadMain(bool, int) [__mutex_base:119]) (BuildId: 96ebb8645e58a6a93394d2844ca09a10e3924d28)
#07 pc 0x196dd90 libAirwar.so (void* std::__ndk1::__thread_proxy<std::__ndk1::tuple<std::__ndk1::unique_ptr<std::__ndk1::__thread_struct, std::__ndk1::default_delete<std::__ndk1::__thread_struct> >, std::__ndk1::function<void ()> > >(void*) [functional:1884]) (BuildId: 96ebb8645e58a6a93394d2844ca09a10e3924d28)
#08 pc 0x10cbd8 libc.so (BuildId: 4425ba3ccfed552700ceb9be545d3599)
#09 pc 0xa64a4 libc.so (BuildId: 4425ba3ccfed552700ceb9be545d3599)

These callstacks are coming from a thread that I do not recognize (i.e. it wasn't created by me explicitly).

We don't have more info than this unfortunately.

I tried to inspect the source code. Usually this type of bugs mean that mThreadPool got resized/cleared while it was being accessed. But as far as I can see all accesses to mThreadPool are correctly guarded by mThreadPoolMutex.

However I did find these two oddities:

Oddity 1: Possible race condition

    Settings::getInstance()->addListener([this]() { onSettingsChanged(); });

    std::lock_guard<std::mutex> lock(mThreadPoolMutex);
    mUseAffinity = Settings::getInstance()->getUseAffinity();
    launchThreadsLocked();

Because the listener is added before the threads are spawned, theoretically it is possible that onSettingsChanged() gets called before the mThreadPoolMutex is locked. This would cause launchThreadsLocked() to be called twice and end up with twice the amount of spawn threads as intended. This could be a bug.

If this is actually happening, there would be other bugs too (e.g. mUseAffinity is still uninitialized and onSettingsChanged() will attempt to read from it).

It may be fixed by moving the addListener() call after launchThreadsLocked().

Oddity 2: mThreadPool is not reserved

    const int32_t numThreads = getNumCpus() > 2 ? 2 : 1;
    for (int32_t thread = 0; thread < numThreads; ++thread) {
        mThreadPool.push_back(
            Thread([this, thread]() { threadMain(mUseAffinity, thread); }));
    }

A rare bug in copy or move semantics could cause this code to malfunction if reallocation becomes necessary. It may be wise to reserve first:

    const int32_t numThreads = getNumCpus() > 2 ? 2 : 1;
    mThreadPool.reserve(numThreads);
    for (int32_t thread = 0; thread < numThreads; ++thread) {
        mThreadPool.push_back(
            Thread([this, thread]() { threadMain(mUseAffinity, thread); }));
    }

I doubt this is the cause of the bug though.