Bug 14973

I took a look at what differs, and attached diffs of 'objdump -x' and 'objdump -d'. If you look at them, it seems as though there is a non-determinism in this function (from build/WebCore/DerivedSources/CSSPropertyNames.cpp):

CSSPropertyID CSSProperty::resolveDirectionAwareProperty(CSSPropertyID propertyID, TextDirection direction, WritingMode writingMode)
{
    const TextFlow& textflow = makeTextFlow(writingMode, direction);
    switch (propertyID) {
    case CSSPropertyID::CSSPropertyBlockSize: {
        static constexpr CSSPropertyID properties[2] = { CSSPropertyWidth, CSSPropertyHeight };
        return properties[static_cast<size_t>(mapLogicalAxisToPhysicalAxis(textflow, LogicalBoxAxis::Block))];
    }
    case CSSPropertyID::CSSPropertyInlineSize: {
        static constexpr CSSPropertyID properties[2] = { CSSPropertyWidth, CSSPropertyHeight };
        return properties[static_cast<size_t>(mapLogicalAxisToPhysicalAxis(textflow, LogicalBoxAxis::Inline))];
    }
    case CSSPropertyID::CSSPropertyBorderBlockEnd: {
        static constexpr CSSPropertyID properties[4] = { CSSPropertyBorderTop, CSSPropertyBorderRight, CSSPropertyBorderBottom, CSSPropertyBorderLeft };
        return properties[static_cast<size_t>(mapLogicalSideToPhysicalSide(textflow, LogicalBoxSide::BlockEnd))];
    }
    case CSSPropertyID::CSSPropertyBorderBlockStart: {
        static constexpr CSSPropertyID properties[4] = { CSSPropertyBorderTop, CSSPropertyBorderRight, CSSPropertyBorderBottom, CSSPropertyBorderLeft };
        return properties[static_cast<size_t>(mapLogicalSideToPhysicalSide(textflow, LogicalBoxSide::BlockStart))];
    }
    case CSSPropertyID::CSSPropertyBorderInlineEnd: {
        static constexpr CSSPropertyID properties[4] = { CSSPropertyBorderTop, CSSPropertyBorderRight, CSSPropertyBorderBottom, CSSPropertyBorderLeft };
        return properties[static_cast<size_t>(mapLogicalSideToPhysicalSide(textflow, LogicalBoxSide::InlineEnd))];
    }
....

Specifically that those static arrays that are declared in each block do not have deterministic naming and order of being placed into rodata section. The compiler pools the 'same' ones together to save memory, but gives several names to each.

The .cpp file itself is generated with makeprop.pl from a json list of css properties, however I believe that is deterministic: the loop to produce the case statements specifically sorts the list of items it's working on.

Created attachment 4913 [details]
objdump -d output diff

Created attachment 4914 [details]
objdump -x output diff

Potentially a gcc intermittent error that may be fixed with a carefully selected sort but let's see if this happens again.

Not seen in 2 months. Re-open if seen again.