Bug 126014

Summary: REGRESSION: Frequent assertion failures on printing/print-close-crash.html
Product: WebKit Reporter: Alexey Proskuryakov <ap>
Component: WebKit2Assignee: Nobody <webkit-unassigned>
Status: RESOLVED FIXED    
Severity: Normal CC: andersca, cfleizach, darin
Priority: P2 Keywords: Regression
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
URL: http://build.webkit.org/results/Apple%20Mavericks%20Debug%20WK2%20(Tests)/r160850%20(1102)/printing/print-close-crash-crash-log.txt

Description Alexey Proskuryakov 2013-12-19 13:51:05 PST 
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?
Comment 1 chris fleizach 2013-12-19 13:52:56 PST 
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
Comment 2 Alexey Proskuryakov 2013-12-19 14:11:10 PST 
Great idea, I could reproduce with:

./Tools/Scripts/run-webkit-tests accessibility printing --child-processes=1 --batch-size=100000 -2 —debug
Comment 3 Alexey Proskuryakov 2013-12-19 15:22:32 PST 
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.
Comment 4 Alexey Proskuryakov 2013-12-19 15:30:00 PST 
Landed the rollout in <http://trac.webkit.org/r160866>.