ExportXMLWordPrintableJSON

    • Type: Bug
    • Resolution: Unresolved
    • Priority: Major - P3
    • None
    • Affects Version/s: None
    • Component/s: Cache and Eviction
    • None
    • Storage Engines - Transactions
    • 456.263
    • SE Transactions - 2026-10-23, SE Transactions - 2026-11-06
    • 5

      Hit this on a patch, not on mainline on format-stress-test-disagg-multi-snapshot-read-1 }}{{amazon2023-stress-tests-arm64 (linked in comment) aborted with a SIGABRT and core dump.

      stack

      #3  __wt_abort                    src/os_common/os_abort.c:32
      #4  __split_multi_inmem           src/btree/bt_split.c:1698
      #5  __wt_split_rewrite            src/btree/bt_split.c:2576
      #6  __evict_page_dirty_update     src/evict/evict_page.c:899
      #7  __wt_evict                    src/evict/evict_page.c:706
      #8  __wti_evict_page              src/evict/evict_dispatch.c:254
      #9  __wti_evict_lru_pages         src/evict/evict_queue.c:140
      #10 __evict_pass                  src/evict/evict_thread.c:696
      #11 __evict_server                src/evict/evict_thread.c:198
      
      • bt_split.c:1698 on develop is WT_ASSERT(session, prev_onpage->next == tmp). the CI log only has the SIGABRT and stack, not the assertion text, so that's read from the source line. 
      • it's the "restore this update chain" check: after walking from the onpage update, the next update should be the one we decided to restore.
      • seeds: random.data_seed=6531864, random.extra_seed=3147232

      command

      ./t -c ../../../test/format/CONFIG.disagg disagg.multi=1 disagg.multi_validation=1 disagg.snapshot_read=1 runs.predictable_replay=1 runs.rows=50000:200000 runs.ops=500000:2000000
      

      resolved config: rows=80000, ops=2000000, 3 tables, 19 threads, leader mode, palite page log.

      things in the config that look relevant

      • stress.failpoint_eviction_split=1 }}(fails 1% of eviction splits with {{{}EBUSY, see __split_multi_lock)
      • ops.prepare=1, preserve_prepared=0, precise_checkpoint=1
      • tiny memory_page_max: table1=4, table3=1
      • table1 is delete heavy (pct.delete=13)

      not reproduced yet

      • ran the full resolved CONFIG locally (macOS, Debug+diagnostic) 7 times on the patch branch and 6 times on plain develop. all passed, so no local repro. likely needs linux/arm64 or just more iterations, it only failed once in 10 here.

      not the victim cache

      • the patch was WT-18808 (palite victim cache sizing), but the victim cache was off in this run. no victim_cache option is set anywhere in the CONFIG or the task definition, both palite bounds default to 0, and the diff doesn't touch bt_split.c or evict.
      • I couldnt find pre-existing BF/BFG. 

            Assignee:
            [DO NOT USE] Backlog - Storage Engines Team
            Reporter:
            Mariam Mojid
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated: