Bug 14973 - webkitgtk is not reproducible
Summary: webkitgtk is not reproducible
Status: RESOLVED FIXED
Alias: None
Product: OE-Core
Classification: Build System, Metadata & Runtime
Component: core (show other bugs)
Version: unspecified
Hardware: x86 Multiple
: Medium+ normal
Target Milestone: 4.2 M2
Assignee: Unassigned
QA Contact:
URL:
Whiteboard: AB-INT
Depends on:
Blocks:
 
Reported: 2022-11-22 16:37 UTC by Alexandre Belloni
Modified: 2023-02-02 15:53 UTC (History)
5 users (show)

See Also:
OS type for building Yocto: ---
Type of Regression: ---
Verified:
Documentation change: No (bug/feature does not impact docs)


Attachments
objdump -d output diff (38.94 KB, text/plain)
2022-11-24 12:20 UTC, Alexander Kanavin
no flags Details
objdump -x output diff (17.77 KB, text/plain)
2022-11-24 12:21 UTC, Alexander Kanavin
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Comment 1 Alexander Kanavin 2022-11-24 12:20:02 UTC
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.
Comment 2 Alexander Kanavin 2022-11-24 12:20:42 UTC
Created attachment 4913 [details]
objdump -d output diff
Comment 3 Alexander Kanavin 2022-11-24 12:21:05 UTC
Created attachment 4914 [details]
objdump -x output diff
Comment 4 Randy MacLeod 2022-11-24 15:37:43 UTC
Potentially a gcc intermittent error that may be fixed with a carefully selected sort but let's see if this happens again.
Comment 5 Randy MacLeod 2023-02-02 15:53:36 UTC
Not seen in 2 months. Re-open if seen again.