summaryrefslogtreecommitdiff
path: root/coroutine/asyncify
diff options
context:
space:
mode:
authorKJ Tsanaktsidis <kj@kjtsanaktsidis.id.au>2023-11-27 17:33:08 +1100
committernagachika <nagachika@ruby-lang.org>2024-11-22 08:06:01 +0900
commit9e1a78059dc1c2bee1159f7626a15de689f4fc1c (patch)
treed804e79a770c6fff4e727b422d0936808e5cb646 /coroutine/asyncify
parent9aa313f2f8ce2a437fe027a5d757f957b9aad5c8 (diff)
Fix flaky "Expected 499 to be >= 500" assertion in test_gc_compact.rb
There have been some sproradically flaky tests related to GC compaction, which fail with: 1) Failure: TestGCCompact#test_moving_hashes_down_size_pools [/test/ruby/test_gc_compact.rb:442]: Expected 499 to be >= 500. What's happening here, is that, _sometimes_, depending on very unlucky combinations of machine things, one of the expected-to-be-moved hashes might be found on the machine stack during GC, and thus pinned. One factor which seems to make this _more_ likely is that GCC 11 on Ubuntu 22.04 seems to want to allocate 440 bytes of stack space for `gc_start`, which is much more than it actually uses on the common code path. The result is that there are some 50-odd VALUE-sized cells "live" on the stack which may well contain valid heap pointers from previous function calls, and will need to be pinned. This is, of course, totally normal and expected; Ruby's GC is conservative and if there is the possibility that a VALUE might be live on the machine stack, it can't be moved. However, it does make these tests flaky. This commit "fixes" the tests by performing the work in a fiber; the fiber goes out of scope and should be collected by the call to verify_compaction_references, so there should be no references to the to-be-moved objects floating around on the machine stack. Fixes [#20021]
Diffstat (limited to 'coroutine/asyncify')
0 files changed, 0 insertions, 0 deletions