Summary
The root cause beneath the #603 catalog crash appears to be a context-sensitivity gap: a 1-CFA context collapse aliases a synthetic-dispatch receiver (an op object) with a list/tuple allocation, so a reflective method-name read lands as a field in the list/tuple's object catalog.
Mechanism (traced from the modeling)
The synthetic do bodies in tensorflow.xml dispatch helper methods via virtual calls, e.g. <call name="read_data" type="virtual" arg0="...">. A virtual call resolves through the trampoline's reflective method lookup, which reads the method name (read_data) off the receiver. That read registers read_data as a reflected field on the receiver's allocation, so it shows up in that allocation's object catalog.
All four read_data virtual calls dispatch on op objects (SparseTensor, Model, the MNIST read_data_sets self), never on a list/tuple. Yet #603 crashes while walking a list/tuple catalog that contains read_data. By elimination, the dispatch receiver's points-to set must alias a list/tuple allocation — i.e., a 1-CFA context collapse mixes the op-object receiver with a list/tuple. That collapse is what drops read_data into a list/tuple catalog alongside its real integer element keys.
Why this is the root, not #603 or #380
Status
Inferred by elimination from the modeling, not yet confirmed by a dumped points-to set. Confirmation needs a reproduction over gpt-2-tensorflow2.0 / TensorFlow-Examples (the subjects that surface #603) with the dispatch-receiver PTS dumped at the polluting read. The fix is context sensitivity sufficient to keep op-object dispatch receivers distinct from list/tuple allocations.
Summary
The root cause beneath the #603 catalog crash appears to be a context-sensitivity gap: a 1-CFA context collapse aliases a synthetic-dispatch receiver (an op object) with a list/tuple allocation, so a reflective method-name read lands as a field in the list/tuple's object catalog.
Mechanism (traced from the modeling)
The synthetic
dobodies intensorflow.xmldispatch helper methods via virtual calls, e.g.<call name="read_data" type="virtual" arg0="...">. A virtual call resolves through the trampoline's reflective method lookup, which reads the method name (read_data) off the receiver. That read registersread_dataas a reflected field on the receiver's allocation, so it shows up in that allocation's object catalog.All four
read_datavirtual calls dispatch on op objects (SparseTensor,Model, the MNISTread_data_setsself), never on a list/tuple. Yet #603 crashes while walking a list/tuple catalog that containsread_data. By elimination, the dispatch receiver's points-to set must alias a list/tuple allocation — i.e., a 1-CFA context collapse mixes the op-object receiver with a list/tuple. That collapse is what dropsread_datainto a list/tuple catalog alongside its real integer element keys.Why this is the root, not #603 or #380
read_datatensor shape not recovered: getFieldIndex crashes on the catalog key, getShapesOfValue NPEs on null #603 (the catalog-filter fix) is the symptom layer: shape inference wrongly assumed catalogs are integer-only, so a stray attribute key crashes it. The filter makes inference robust but doesn't stop the pollution.read_data/read_datasetmarker allocations intensorflow.xml#380 (read_data/read_dataset removal) is the trigger layer: it removes the dominant reflective method-name read, so the collapse stops manifesting as this crash. But it doesn't fix the collapse.read_datais the method name today, any reflective method read on a collapsed receiver can pollute a catalog.Status
Inferred by elimination from the modeling, not yet confirmed by a dumped points-to set. Confirmation needs a reproduction over
gpt-2-tensorflow2.0/TensorFlow-Examples(the subjects that surface #603) with the dispatch-receiver PTS dumped at the polluting read. The fix is context sensitivity sufficient to keep op-object dispatch receivers distinct from list/tuple allocations.