126014 2013-12-19 13:51:05 -0800 REGRESSION: Frequent assertion failures on printing/print-close-crash.html 2013-12-19 15:30:00 -0800 1 1 1 Unclassified WebKit WebKit2 528+ (Nightly build) Unspecified Unspecified RESOLVED FIXED http://build.webkit.org/results/Apple%20Mavericks%20Debug%20WK2%20(Tests)/r160850%20(1102)/printing/print-close-crash-crash-log.txt Regression P2 Normal --- 1 ap webkit-unassigned andersca cfleizach darin oldest_to_newest 961529 0 ap 2013-12-19 13:51:05 -0800 printing/print-close-crash.html has started crashing on debug testers, once in 5-10 runs on average. The first crash was on r160493:r160529 range, which makes me strongly suspect <http://trac.webkit.org/changeset/160515>. Unfortunately, I can't reproduce this locally. Perhaps this only happens when accessibility is enabled by an earlier test, and this state is leaked into this printing test? 961531 1 cfleizach 2013-12-19 13:52:56 -0800 One way to test would be to run the accessibility tests first ./Tools/Scripts/run-webkit-tests accessibility printing which would leave on AX during the printing tests. I'll also give it a try 961538 2 ap 2013-12-19 14:11:10 -0800 Great idea, I could reproduce with: ./Tools/Scripts/run-webkit-tests accessibility printing --child-processes=1 --batch-size=100000 -2 —debug 961576 3 ap 2013-12-19 15:22:32 -0800 Chris suggested r160515 to be rolled out for now. I also filed bug 126021 to track the general case, as we do the same thing in many places. I confirmed that undoing r160515 makes the issue no longer occur for me locally. 961581 4 ap 2013-12-19 15:30:00 -0800 Landed the rollout in <http://trac.webkit.org/r160866>.