Android generate_guid leaks a JNI global reference on every call

Open Beginner friendly
#609 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
88/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
android, cpp
Domain
mobile-dev

Research direction

Start in Source/Shared/a/guid.cpp at generate_guid() and inspect the JNI reference handling around FindClass and NewGlobalRef. Verify the chosen reference lifetime against jni_utils.h and global_ref_holder. Done means repeated GUID generation no longer retains an unowned JNI global reference, including failure paths.

Written by the indexing model from the issue text.

Description

Summary

generate_guid() creates a JNI global reference for java.util.UUID and stores it in a local variable. The function never calls DeleteGlobalRef, and nothing else owns that reference. Each call leaks one global ref.

This NewGlobalRef is also unnecessary: a FindClass local ref is enough for this one-shot use.

Location

Source/Shared/a/guid.cppgenerate_guid()

Details

jclass guidClass = jniEnv->FindClass("java/util/UUID");
if (guidClass == nullptr) {
    LOG_ERROR("Could not find UUID class");
    return "";
}
jclass m_guidClass = reinterpret_cast<jclass>(jniEnv->NewGlobalRef(guidClass));
jmethodID generateUuidMethodId = jniEnv->GetStaticMethodID(m_guidClass, "randomUUID", "()Ljava/util/UUID;");
jmethodID uuidToStringMethodId = jniEnv->GetMethodID(m_guidClass, "toString", "()Ljava/lang/String;");

jobject uuidObject = jniEnv->CallStaticObjectMethod(m_guidClass, generateUuidMethodId);
JString rawUuid{ jniEnv, static_cast<jstring>(jniEnv->CallObjectMethod(uuidObject, uuidToStringMethodId)) };

return Format("{%s}", rawUuid.c_str());

· m_guidClass is a function-local. It is not cached on java_interop or any other singleton.
· JNI_ATTACH_THREAD only detaches the thread (thread_holder); it does not delete global refs.
· JString only releases UTF chars; it does not delete m_guidClass.
· The project already has global_ref_holder in jni_utils.h, which calls DeleteGlobalRef in its destructor, but this path does not use it.

JNI global refs persist until DeleteGlobalRef. Repeated GUID generation can grow the global reference table and eventually overflow it.

Suggested fix
Prefer dropping NewGlobalRef and using guidClass directly:

jclass guidClass = jniEnv->FindClass("java/util/UUID");
// GetStaticMethodID / GetMethodID / Call* on guidClass

If a global ref is kept, wrap it with global_ref_holder, or call jniEnv->DeleteGlobalRef(m_guidClass) on every return path (including failures after NewGlobalRef).

Dominant language
C++
Stars
390
Forks
118
PR merge metrics
No merged PRs in 30d

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from microsoft/xbox-live-api

All issues in microsoft/xbox-live-api

Similar issues

More C++ issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.