OfflineStorage_Room::GetAndReserveRecords crash in Android

[FreddyJD]

Describe your environment. Latest 1DS C++ SDK v3.7.62.1

Steps to reproduce.
No repro just a crash report from AppCenter from our Android app.

What is the expected behavior?
N/A

What is the actual behavior?
N/A

Additional context.
This is the crash in appcenter

libmaesdk.so
Microsoft::Applications::Events::OfflineStorage_Room::GetAndReserveRecords(std::__ndk1::function<bool (Microsoft::Applications::Events::StorageRecord&&)> const&, unsigned int, Microsoft::Applications::Events::EventLatency, unsigned int)
libmaesdk.so
Microsoft::Applications::Events::StorageObserver::handleRetrieveEvents(std::__ndk1::shared_ptr<Microsoft::Applications::Events::EventsUploadContext> const&)
libmaesdk.so
Microsoft::Applications::Events::TransmissionPolicyManager::uploadAsync(Microsoft::Applications::Events::EventLatency)
libmaesdk.so
Microsoft::Applications::Events::PlatformAbstraction::WorkerThread::threadFunc(void*)
libmaesdk.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> >, void (*)(void*), void*> >(void*)

We are not sending events right now just initializing:

override fun initialize(context: Context) {
        loadLibraries()
        setupHttpClient(context)
        setupOfflineRoom(context)
        initializeLogger()
    }

    private fun loadLibraries() {
        System.loadLibrary(TelemetryConstants.MAE_SDK_LIB_NAME)
    }

    private fun setupHttpClient(context: Context) {
        HttpClient(context.applicationContext)
    }

    private fun setupOfflineRoom(context: Context) {
        OfflineRoom.connectContext(context.applicationContext)
    }

[anod]

Do you use main thread to initalize Room?

[FreddyJD]

Hi Alex Gavrishev (@anod) It seems so, yes. Is this issue causing crashes for the users? It only affects a small portion of our user base, and we've followed the setup in the repository.

After reviewing the documentation, it appears that Room, HTTP, and the library need to be initialized before we can initialize the loggers.

[anod]

Yes, initialization looks correct,
looking on stack, the crash is happening during uploading an event when it tires to load records from Room DB

Is it possible to add line number to stack trace nd error message?
Do you know if the crash is happening during a specific lifecycle: openning app or closing?

[FreddyJD]

Alex Gavrishev (@anod) App Center reports the only function names where the crash occurs (from native crashes atleast). It appears to be random. Also we are not sending events right now; we are just initializing. So, the issue could be occurring after a background notification, while using the app, or after some time has passed (reporting session times are random)

Question to clarify, is this function called only during the creation of the Room database? Seems that is happening with an Observable that the library sets*

[FreddyJD]

To add more context, we are creating 3 loggers currently.

private fun getLogConfiguration(apiKey: String, teamName: String): ILogConfiguration {
        val config = LogManager.getLogConfigurationCopy().apply {
            set(LogConfigurationKey.CFG_STR_PRIMARY_TOKEN, apiKey)
            set(LogConfigurationKey.CFG_STR_FACTORY_NAME, teamName)
            set(LogConfigurationKey.CFG_STR_FACTORY_HOST, teamName)
        }
        return config
    }

    private fun initializeLogger() {
        if (loggerAuthApp == null) {
            val logConfigAuthApp = getLogConfiguration(TelemetryClientType.AUTHAPP.apiKey, "authapp")
            loggerAuthApp = LogManagerProvider.createLogManager(logConfigAuthApp)
                .getLogger(TelemetryClientType.AUTHAPP.apiKey, "authapp", "")
        }
        if (loggerPIM == null) {
            val logConfigPIM = getLogConfiguration(TelemetryClientType.PIM.apiKey, "pim")
            loggerPIM = LogManagerProvider.createLogManager(logConfigPIM)
                .getLogger(TelemetryClientType.PIM.apiKey, "pim", "")
        }
        if (loggerDID == null) {
            val logConfigDID = getLogConfiguration(TelemetryClientType.DID.apiKey, "did")
            loggerDID = LogManagerProvider.createLogManager(logConfigDID)
                .getLogger(TelemetryClientType.DID.apiKey, "did", "")
        }
    }

[anod]

The trace posted is trying to uploadAsync something, looking in the source, the flow looks following: scheduleUpload >> uploadAsync >> initiateUpload >> retrieveEvents >> handleRetrieveEvents >> GetAndReserveRecords.

May be some stats info is being collected, not familiar with it, you can try to disable stats via configuration and see if it helps

The code crashes when accessing Room DB via GetAndReserveRecords,
I would also suggest to verify that:

• Code that initializes Room, Http client and loggers runs once.
• Code that initializes loggers creates 3 separate database files.

we use the following code, to create multiple loggers:

            val config = LogManager.logConfigurationFactory().apply {
                set(LogConfigurationKey.CFG_STR_PRIMARY_TOKEN, token)
                set(LogConfigurationKey.CFG_STR_COLLECTOR_URL, collectorUrl)
                set(LogConfigurationKey.CFG_STR_FACTORY_NAME, name + UUID.randomUUID())
            }

            val logManager = LogManagerProvider.createLogManager(config)
            return logManager.getLogger(token, "", "")

[zhagao-ms]

Reproduced same crash by upgrade room to from 2.6.1 to 2.7.2

(notice the maesdk still uses room 2.4.3 -

cpp_client_telemetry/lib/android_build/maesdk/build.gradle

Line 75 in a69e537

def room_version = '2.4.3'

)

[hanselip]

See agent analysis on this bug below - going to see if we can issue a fix for this:

---

Confirming this is still active with production-scale impact — adding data to help prioritize.

We're seeing this crash at ~28,000 distinct users / ~39,000 error reports in a 2-week window (Mar 5–19, 2026) in the OneDrive Android app. It's our #4 crash by user impact. We've verified
it is present in both our current and most recent builds.

Stack traces

Two variants, both with identical call chains:

Variant A (majority of reports, BuildId e612766c6f4f55e579f80817f6a7d436747b2948 / 3fb4077f069864f2428130f252c6a2fe9372f8a7):
#00 abort
#1 art::Runtime::Abort
#2 android::base::LogMessage::~LogMessage
#3 art::JavaVMExt::JniAbort
#4 art::JNI::GetObjectClass(_JNIEnv*, _jobject*) ← JNI violation
#5 libmaesdk.so OfflineStorage_Room::GetAndReserveRecords+124
#6 libmaesdk.so OfflineStorageHandler::GetAndReserveRecords+200
#7 libmaesdk.so StorageObserver::handleRetrieveEvents+100
#8 libmaesdk.so TransmissionPolicyManager::uploadAsync+252
#9 libmaesdk.so PlatformAbstraction::WorkerThread::threadFunc+416

Variant B (newer build, BuildId 56596992185df32e147a73a2ff59fe7a616b203e):
#00 art::mirror::Class::FindClassMethod
#1 art::JNI::GetMethodID(_JNIEnv*, _jclass*, char const*, char const*) ← JNI violation
#2 libmaesdk.so OfflineStorage_Room::GetAndReserveRecords+164
#3 libmaesdk.so OfflineStorageHandler::GetAndReserveRecords+200
...same below...

The presence of two different BuildIds with two different JNI failure points (GetObjectClass vs GetMethodID) confirms this is the same underlying bug manifesting slightly differently — not
a fluke.

Root cause

We believe we've identified the specific bug. In GetAndReserveRecords, record_class is a JNI local reference obtained inside a pushLocalFrame(32)/popLocalFrame() scope (introduced in
commit 873b562), but it's declared in the outer loop scope and reused on iterations 2+:

jclass record_class = nullptr; // outer scope

for (index = 0; index < limit; ++index) {
env.pushLocalFrame(32);
auto record = env->GetObjectArrayElement(...);

  if (!record_class) {                           // only true on iteration 0
      record_class = env->GetObjectClass(record);  // local ref in inner frame
      id_id = env->GetFieldID(record_class, ...);
      // ...
  }

  env.popLocalFrame();   // frees the inner frame → record_class is now stale
  // iteration 1: record_class != nullptr but points into freed frame
  //              → ART JniAbort → SIGABRT

}

ART's JNI reference validity checking (which has gotten stricter over recent Android releases) detects the stale reference and calls JniAbort. The same pattern exists in ReleaseRecords
(bt_class) and GetRecords (record_class).

The fix is to promote record_class to a global reference before popLocalFrame():
jclass local_class = env->GetObjectClass(record);
record_class = static_cast(env->NewGlobalRef(local_class));
// ... and DeleteGlobalRef when done
This matches the pattern already used for m_room and s_context elsewhere in the same file.

Important: bumping to latest HEAD does not fix this

We checked — OfflineStorage_Room.cpp is byte-for-byte identical between our pinned commit (97f7f8f) and the current HEAD (bc01119). The file has not been modified since August 2021.

Affects API levels 27–36, arm32 and arm64. Happy to provide additional stack samples if useful.

[lalitb]

Hansel Ip (@hanselip) Thanks for the analysis. The proposed direction looks reasonable to me as a candidate fix. If the issue is that a cached jclass local ref is surviving past popLocalFrame(), then promoting it to a global ref and deleting it when done would be the standard JNI-safe way to preserve it across iterations. If you’re able to, could you please send a PR for this? It would also be worth checking ReleaseRecords and GetRecords for the same pattern so we do not fix only one manifestation of the problem.