[scheduled-gate:gc-root-dominance.yml] GC Root Dominance is failing on main #9925

Activity

1. proggeramlug commented on Sep 7, 2026

   

   proggeramlug

   on Sep 7, 2026

   Contributor

   More actions

   Fixed by #9929, landed on main via merge train #9939. The train merged as its own branch, so the close-keyword never fired — closing manually, verified on main.
2. proggeramlug

   closed this as completedon Sep 7, 2026
3. github-actions

   reopened this on Sep 11, 2026
4. github-actions commented on Sep 11, 2026

   

   github-actionsbot

   on Sep 11, 2026 – with GitHub Actions

   Author

   More actions

   Green again at 1a9c0de6cb79; closing automatically.
5. github-actions

   closed this as completedon Sep 11, 2026
6. github-actions

   reopened this on Sep 13, 2026
7. proggeramlug commented on Sep 13, 2026

   

   proggeramlug

   on Sep 13, 2026

   Contributor

   More actions

   Diagnosis of the current red run (scheduled run 34755757397 on 820cf76729; also red at 8a058e2053):

   1. The job stops before the corpus is checked. python3 scripts/gc_root_dominance_check.py --audit-poll-capable exits 2:

      error: POLL_CAPABLE_RUNTIME entries that name no runtime symbol:
        js_string_replace_all_regex_fn
        js_string_replace_regex_fn
      

      Both symbols disappeared when Perex became the only regex engine (Make Perex the runtime's only regular-expression engine #10142, merge train Merge train 170: #10142 #10146). Per the audit's own message, the fix is to replace them with the symbols codegen now emits for a callback replace/replaceAll, not just delete them.

   2. Behind that, the corpus is not clean. Running scripts/gc_root_dominance_corpus.sh <out> --lowering shadow and then gc_root_dominance_check.py <out> locally (macOS arm64) gives 2 violations, both non-moving:

      test_gap_gc_regexp_receiver_rooting__...ts.ll::perry_fn_test_gap_gc_regexp_receiver_rooting_ts__run
        alloc  : call i64 @js_regexp_site_test_new(...)
        bind   : slot 1  call void @js_shadow_slot_bind(i32 1, ...)
        between: js_regexp_site_test_get_method
        MOVING : no
      

      I checked this is not new: compiling test-files/test_gap_gc_regexp_receiver_rooting.ts with a 9b911855f8 release compiler (PERRY_RS4GC=0 PERRY_GC_MOVING_LOOP_POLLS=1 PERRY_INLINE_SHADOW_SLOT=0 --trace llvm) reproduces the same two fingerprints. The allowlist is empty, so once step 1 is fixed this job will stay red on these until the site-test lowering binds the new receiver before js_regexp_site_test_get_method, or they are allowlisted with an issue.

   (Found while validating a merge train; neither finding is caused by that train.)
8. github-actions commented on Sep 22, 2026

   

   github-actionsbot

   on Sep 22, 2026 – with GitHub Actions

   Author

   More actions

   Green again at f5cfbff88284; closing automatically.
9. github-actions

   closed this as completedon Sep 22, 2026
10. github-actions

    reopened this on Sep 27, 2026
11. TheHypnoo commented on Sep 28, 2026

    

    TheHypnoo

    on Sep 28, 2026

    Member

    More actions

    Related manual tracker: #8821 (gc-root-dominance is structurally dark). Also related: #11496 (--verify-symbols always fails on Linux/LTO archives).
12. github-actions commented on Sep 28, 2026

    

    github-actionsbot

    on Sep 28, 2026 – with GitHub Actions

    Author

    More actions

    Green again at 295473cd5c4f; closing automatically.
13. github-actions

    closed this as completedon Sep 28, 2026
14. github-actions

    reopened this on Oct 3, 2026
15. github-actions commented on Oct 4, 2026

    

    github-actionsbot

    on Oct 4, 2026 – with GitHub Actions

    Author

    More actions

    Green again at 0a5bb47dc5f1; closing automatically.
16. github-actions

    closed this as completedon Oct 4, 2026
17. github-actions

    reopened this on Oct 6, 2026