Android generate_guid leaks a JNI global reference on every call
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.cpp — generate_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
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from microsoft/xbox-live-api
-
Difficulty 5/5 Over a week Newbie friendliness 15/100
microsoft/xbox-live-api#607 ·
-
Difficulty 5/5 Over a week Newbie friendliness 1/100
microsoft/xbox-live-api#605 ·
-
Difficulty 4/5 3-5 days Newbie friendliness 25/100
microsoft/xbox-live-api#594 ·
-
Difficulty 3/5 1-2 days Newbie friendliness 25/100
microsoft/xbox-live-api#590 · 2 comments · 1 reaction ·
All issues in microsoft/xbox-live-api
Similar issues
-
Difficulty 1/5 Under an hour Newbie friendliness 90/100
AXERA-TECH/ax-llm#77 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
-
bug-unconfirmed
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
NVIDIA/cuda-samples#453 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
infiniflow/infinity#3502 ·