The new construct-return-early-from-infinite-loop-for-fuzzer.js test added in r266770 "[JSC] returnEarlyFromInfiniteLoopsForFuzzing should return object" loops forever on llint, but only on x86_64. Other architectures seems to be fine. (So this doesn't affect any architectures that commonly use llint, but x86_64 is great to have working as a baseline to see when problems occur only on a particular architecture.)
(In reply to Michael Catanzaro from comment #0) > The new construct-return-early-from-infinite-loop-for-fuzzer.js test added > in r266770 "[JSC] returnEarlyFromInfiniteLoopsForFuzzing should return > object" loops forever on llint, but only on x86_64. Other architectures > seems to be fine. (So this doesn't affect any architectures that commonly > use llint, but x86_64 is great to have working as a baseline to see when > problems occur only on a particular architecture.) Did you mean when using CLoop (JIT disabled at compile time)? Or with LLInt compiled with the x86_64 backend (default) and disabling higher tiers at runtime? FWIW x86_64 does use LLInt as its first tier by default.
Yes, this is with cloop enabled and JIT disabled. (The point of testing cloop on x86_64 is to distinguish between architecture-specific bugs and general cloop bugs.)
Is there anything I should try running that could maybe help with debugging this? It hangs our internal Jenkins builder, and I'm starting to get nervous about missing CI coverage since it's now been a week since the regression landed.
I think maybe returnEarlyFromInfiniteLoopsForFuzzing's loop-hint thing is not supported in CLoop...? For now, I'll put `isUseJIT()` check
Committed r267115: <https://trac.webkit.org/changeset/267115>
<rdar://problem/68950461>
OK, thanks Yusuke! $vm.useJIT() will certainly guarantee the test doesn't run.