Found while enabling the vips driver on JRuby (#243). Separate from the timeout budget — a longer timeout cannot fix a hang.
Symptom
JRuby cells stall intermittently and seed-dependently. One cell completed 600 runs in 8m17s; another reached only ~230 of 600 tests in 15 minutes at seed 29927.
Diagnosis
Reproduced locally and inspected with jstack: the tests finish, then JRuby blocks forever during interpreter teardown:
Ruby.tearDown -> ThreadService.teardown -> Thread.join
waiting on leftover threads — a puma reactor thread and a thread from ferrum/utils/thread.rb. On MRI these threads are killed at exit; JRuby's teardown joins them instead, so a non-daemon leftover thread hangs the process after a successful run.
Why it matters now
The JRuby cells have effectively not been gating anything: they were cancelled by the 7-minute per-attempt budget on master. #243 raises that to 15 minutes, which covers the legitimate 8m17s run — but a hung cell will still burn the full budget and cancel.
Likely direction (not investigated)
Ensure the test harness shuts down the Capybara server and the browser driver's threads before exit on JRuby, or mark them daemon. Worth checking whether Capybara.reset_sessions!/server shutdown runs in an at_exit that JRuby orders differently.
Evidence
- passing cell:
Test Ruby & Rails (jruby-10.0, rails72_gems.rb) with SCREENSHOT_DRIVER=vips, 600 runs / 1690 assertions / 0 failures / 1 skip in 8m17s
- vips itself is not implicated: it is faster than chunky_png on JRuby (390.4s vs 434.4s, same machine, only
SCREENSHOT_DRIVER differing)
Found while enabling the vips driver on JRuby (#243). Separate from the timeout budget — a longer timeout cannot fix a hang.
Symptom
JRuby cells stall intermittently and seed-dependently. One cell completed 600 runs in 8m17s; another reached only ~230 of 600 tests in 15 minutes at seed 29927.
Diagnosis
Reproduced locally and inspected with
jstack: the tests finish, then JRuby blocks forever during interpreter teardown:waiting on leftover threads — a
puma reactorthread and a thread fromferrum/utils/thread.rb. On MRI these threads are killed at exit; JRuby's teardown joins them instead, so a non-daemon leftover thread hangs the process after a successful run.Why it matters now
The JRuby cells have effectively not been gating anything: they were cancelled by the 7-minute per-attempt budget on master. #243 raises that to 15 minutes, which covers the legitimate 8m17s run — but a hung cell will still burn the full budget and cancel.
Likely direction (not investigated)
Ensure the test harness shuts down the Capybara server and the browser driver's threads before exit on JRuby, or mark them daemon. Worth checking whether
Capybara.reset_sessions!/server shutdown runs in anat_exitthat JRuby orders differently.Evidence
Test Ruby & Rails (jruby-10.0, rails72_gems.rb)withSCREENSHOT_DRIVER=vips, 600 runs / 1690 assertions / 0 failures / 1 skip in 8m17sSCREENSHOT_DRIVERdiffering)