Bug 126014 - REGRESSION: Frequent assertion failures on printing/print-close-crash.html
Summary: REGRESSION: Frequent assertion failures on printing/print-close-crash.html
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit2 (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL: http://build.webkit.org/results/Apple...
Keywords: Regression
Depends on:
Blocks:
 
Reported: 2013-12-19 13:51 PST by Alexey Proskuryakov
Modified: 2013-12-19 15:30 PST (History)
3 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
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>.