memory corruption on flutter stable

[mraleph]

I have a report of a bug and an APK produced by stable branch of Flutter with is experiencing random crashes which look like a memory corruption issue.

These crashes manifest in few different ways, sporadically:

• Hitting release assert when trying to throw a null noSuchMethod exception: we see null at a dispatch table call site which does not expect null to be present - as a result we hit an assertion when trying to locate NullCheck name in the CodeSourceMap (callsite does not expect null - so no null check information was recorded)
• Hitting crash in scavenger when trying to copy something that looks like a stale pointer into new space, the pointer itself originates from a Context object which otherwise looks valid
• Various crashes in the generated code, I am trying to go through call stack and locate where illegal object came from - but sometimes it is impossible to establish

Initial I suspected a missing barrier for a context object, but running with store buffer verification did not catch it), which probably means that the stale pointer originated from somewhere else.

@rmacnak-google do you remember fixing any GC issues since stable branch?

/cc @mkustermann

[mraleph]

I am looking deeper in a specific, crash - I can a see that an instance of TextFormField has corrupted field controller. TextFormField itself resides in the new space above survivor boundary - which means it was just allocated since last GC. Corrupted value in the controller field is pointing into new space as well, but above the top - which means it is some stale value which was not updated by the GC. We need to understand where this value came from next.

[rmacnak-google]

Flutter 1.17.1 maps to Dart ae8b224. This revision doesn't have parallel scavenge or paged new-space. There haven't been any GC or missing write barrier fixes since this branch point (except fixes to parallel scavenge).

[mraleph]

After a good night of sleep I woke up realising that 76bff1e was not cherry picked into stable - and it can cause exactly the kind of bug we are seeing here because visitors get confused on large objects with unboxed fields (essentially if field at offset X is unboxed then fields at offsets X + 64*8 are also considered unboxed).

So I cherry picked the fix and confirmed that both APKs I have access to are now working.