Exhausted heap space, trying to allocate 9301736656 bytes. about flutter HOT 3 OPEN

This issue will be discussed in person next week, but here is some info for future reference:

The current flutter stable (5.22.2) depends on version 5.8.8+1 of unified_analytics¹. The relevant code. The crash happens at L285:

    var records = logFile.readAsLinesSync();

Given that this read tried to allocate >9GB, I assume then that this log file somehow reached ~9GB in size. This is surprising, because we limit the number of event payloads we keep saved to kLogFileLength (2500). From here, I hypothesize that one or more payloads that got logged were massive.

This almost certainly means that we have a bug somewhere (either in unified_analytics, but more likely the flutter tool). I can't imagine any legitimate reason for a payload being somewhere between somewhere between 9GB/2500=3.6MB and 9GB in size. Another reason this is troubling is that we are potentially wasting a significant amount of the user's network bandwidth².

Focusing back on the issue on allocating 9GB. I/@christopherfujino see two ways forward:

1. Patch unified_analtyics (v5 and v6) to stop this logging completely.
2. Rework the troublesome code to more robustly guard against massive payloads. Just as one example, instead of constraining the file using number of payloads logged, we could discard any payload (new or existing) that exceeds 1kB. In this case I would also recommend patching this code to catch and discard any FileSystemException encountered—the risk of such an exception is completely opaque to callers, and logging these payloads is not important enough to warrant crashing callers. This was already patched into v6 with 6.1.1, but we should probably do this for v5 as well and get this hotfixed into the stable flutter release.

from flutter.

@andrewkolos we should take a look at this one

from flutter.

2. Maybe we should file another issue on this? Either the tool should add guards that make sure we aren't sending massive payloads, or we could make the Analytics class (from unified_analtyics) configurable with a means to guard against this. Opinions, @christopherfujino ? ↩

I talked with @christopherfujino briefly (this is still going to be discussed more next week). He agreed that we should do something about sending massive payloads. Perhaps we should continue to send these (to avoid events "disappearing" in a confusing way), but we should also send a special "large event" event when this happens. We can then then triage these special events independently. It's also entirely possible that we can already query our analytics for massive payloads and troubleshoot from there, but this is something we would need to investigate.

from flutter.