Fix race condition caused by mstats replacing it call with malloc_zone_statistics(). #15501

[JesusRojass]

EDIT. Initially this PR involved replacing mstats with task info, given comments a new approach was found and tested!

This fix replaces mstats() call with malloc_zone_statistics() for collecting heap memory usage in FPRMemoryGaugeCollector.

The original implementation using mstats() could crash under heavy allocation contention due to lock issues in the malloc subsystem. malloc_zone_statistics(nil, &stats) provides the same heap-specific metrics (size_in_use) with a simpler call path.

This should fix issue #15501

Testing

• All unit tests working as expected

API Changes

• No API Changes

[gemini-code-assist]

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

[JesusRojass]

/gemini review

[gemini-code-assist]

Code Review

This pull request addresses a race condition by replacing mstats() with the more modern task_info() for memory metric collection, which is a great improvement for stability. My review focuses on improving the clarity and maintainability of the new implementation. I've suggested removing a now-redundant variable and a block of dead code. I also noted that the collected memory metric has changed semantically from heap usage to physical memory footprint, and recommended updating internal data structures and comments to reflect this to avoid future confusion. Overall, these changes are positive, and addressing the feedback will further enhance the code quality.

[JesusRojass]

/gemini review

[gemini-code-assist]

Code Review

This pull request addresses a race condition in memory metric collection by replacing the usage of mstats with the more modern and thread-safe task_info API. This is a solid improvement for stability. The implementation correctly uses task_info to get the physical memory footprint. My review includes a suggestion to improve error logging and raises a point about the naming of the collected metric, which has semantically changed from heap usage to physical memory footprint, potentially causing confusion.

[JesusRojass]

/gemini review

[gemini-code-assist]

Code Review

This pull request effectively addresses a race condition by replacing the mstats() call with the more modern and thread-safe task_info() for memory usage measurement. This is a great improvement for the stability of the SDK. The change from measuring heap usage to physical memory footprint is clearly communicated through updated comments, and the removal of the now-unavailable heapAvailable metric is handled correctly. The implementation is solid, and I have just one minor suggestion to further improve type safety.

[salimbraksaext]

We’re seeing this crash in our app as well. As a temporary workaround, we’ll point our Firebase SDK to this branch until the fix is released.

[JesusRojass]

@salimbraksaext Let me know if you encounter any issues!

[CtrlJone]

Hello, when will the merge be available? Our app is also experiencing a similar crash, version 12.6.0.

[visumickey]

I don't think task_info and mstats() are comparably replaceable. mstats() provides heap usage and other memory related usage. task_info to get the VM_INFO provides the overall system wide RAM usage. I don't think we should replace the mstats with this API.

An API that could consider to find the heap usage could be malloc_statistics_t. I have not explored deeper on this API, but stumbled on this API to provide memory information.

Something like below:

    var stats = malloc_statistics_t()
    // We request statistics for the default malloc zone
    malloc_zone_statistics(nil, &stats)
    // 'stats.size_in_use' is the actual bytes currently allocated on the heap

[JesusRojass]

I don't think task_info and mstats() are comparably replaceable. mstats() provides heap usage and other memory related usage. task_info to get the VM_INFO provides the overall system wide RAM usage. I don't think we should replace the mstats with this API.

An API that could consider to find the heap usage could be malloc_statistics_t. I have not explored deeper on this API, but stumbled on this API to provide memory information.

Something like below:

    var stats = malloc_statistics_t()
    // We request statistics for the default malloc zone
    malloc_zone_statistics(nil, &stats)
    // 'stats.size_in_use' is the actual bytes currently allocated on the heap

@visumickey Working on a better approach for this

[CtrlJone]

@JesusRojass , hello In which version are you expecting to fix this crash? We've been experiencing a lot of these crashes online lately! Or can anyone tell me which version is more stable and won't have this crash?

[JesusRojass]

@CtrlJone hello there
This is not merged at the moment and needs some tuning before it is ready which I hope to have by tomorrow! And then get re reviewed

Hoping soon on the latest version

[JesusRojass]

@visumickey Ready for review!

[CtrlJone]

@visumickey , hello In which version are you expecting to fix this crash? We've been experiencing a lot of these crashes online lately! Or can anyone tell me which version is more stable and won't have this crash?

[visumickey]

For the freeHeap available, can we check if we can measure that using the below lines of code?

uint64_t usedBytes = stats.size_in_use;
uint64_t totalHeapBytes = stats.size_allocated;
uint64_t freeInsideHeap = totalHeapBytes - usedBytes;

[visumickey]

Feel - this should ideally be not hardcoded to 0. Can we change this to freeInsideHeap what we measured in the earlier commend?

[JesusRojass]

Sure thing!