Investigation and Fix of Android Native Crash in CookieManager.getCookie Caused by Thread‑Unsafe GURL Initialization

Background

On the Android platform a long‑standing native crash occurs when an app calls CookieManager.getCookie(String url) . The crash appears across Android 4.1‑9.0, mainly during app startup, and has been a top‑3 native crash in the Xigua Video app for a long time, accounting for over 40% of the top‑10 native crashes and more than 30% of all native crashes, affecting over 0.1% of users.

Native Stack

Java Stack

(More than 50% of the crashes have no Java stack)

Investigation Approach

The crash stack only contains .so and offset information without function names, making direct diagnosis difficult. The key is to locate a stack with clear function names, then map those functions to the AOSP source to pinpoint the root cause.

Preliminary Investigation

Although the affected Android versions and devices are diverse, most stacks lack core crash‑related functions. A notable exception is a crash on Android 4.2.2 that includes the function _ZN4GURLC2ERKSs (GURL::GURL(const std::string&)).

Analyzing the Android 4.2.2 GURL source revealed a very broad code base, making it hard to locate the exact memmove call that triggers the crash.

Experiments showed that crashes happen when multiple threads invoke CookieManager.getCookie simultaneously, suggesting a thread‑safety issue.

Further inspection uncovered stacks containing ZN8url_util20LowerCaseEqualsASCIIEPKcS1_S1 , indicating involvement of URL utilities.

Additional stacks showed crashes in GURL constructors, some related to vector operations, which are not thread‑safe, reinforcing the thread‑safety hypothesis.

In‑Depth Analysis

The function url_util::LowerCaseEqualsASCII(const char*, const char*, const char*) appears in the crash stack, ultimately leading to a null third argument (b) in the call, causing a null‑pointer dereference.

Register analysis (PC=0x5cb1453e) confirms that R2 (the third argument) is null.

Two locations call this function within the GURL constructor chain: CompareSchemeComponent and DoIsStandard . The former passes a constant scheme ( kFileScheme ), which cannot be null, so it is ruled out.

The latter uses a global variable initialized lazily in InitStandardSchemes . This lazy initialization is not protected by a lock, and std::vector is not thread‑safe, leading to possible race conditions when multiple threads initialize or read standard_schemes simultaneously.

Chromium source shows that this thread‑unsafe GURL initialization existed in Android 4.0‑9.0 and was fixed on 2019‑05‑21, but older Chromium versions on Android < 10 still contain the bug, requiring an application‑level mitigation.

Fix Solution

Ensuring that only one thread can execute the standard_schemes initialization resolves the issue. The Xigua Video app adds a synchronization guard around the first execution of CookieManager.getCookie using a custom AOP hook, releasing the lock after the first successful run.

After rolling out the fix in version 432, the crash disappeared with minimal cost.

Conclusion

Symbol information is essential when investigating native crashes, but many crashes lack it. Rare device or Android version crashes may retain useful symbols and should not be ignored. Developers should encourage manufacturers to preserve key symbol tables. While online sources like androidxref.com and cs.android.com are helpful, they do not cover all Android versions; the full source can be obtained from android.googlesource.com for comprehensive offline analysis.