Bug 107981

Summary: [skia] Check for null-device when calling createCompatibleDevice
Product: WebKit Reporter: Mike Reed <reed>
Component: New BugsAssignee: Mike Reed <reed>
Status: RESOLVED FIXED    
Severity: Normal CC: fmalita, jamesr, junov, senorblanco, webkit.review.bot
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
Patch
none
Minimized test, crashes in Chromium. none

Mike Reed
Reported 2013-01-25 13:18:38 PST
Check for null-device when calling createCompatibleDevice
Attachments
Patch (1.44 KB, patch)
2013-01-25 13:22 PST, Mike Reed 		no flags
DetailsFormatted DiffDiff
Minimized test, crashes in Chromium. (305 bytes, text/html)
2013-01-26 12:26 PST, Florin Malita 		no flags
Details
View All Add attachment proposed patch, testcase, etc.
Mike Reed
Comment 1 2013-01-25 13:22:16 PST
Created attachment 184802 [details] Patch
James Robinson
Comment 3 2013-01-25 13:29:20 PST
Comment on attachment 184802 [details] Patch Can we make a test that tries to construct a really big ImageBuffer?
Florin Malita
Comment 4 2013-01-26 12:26:29 PST
Created attachment 184880 [details] Minimized test, crashes in Chromium.
Florin Malita
Comment 5 2013-01-26 12:36:48 PST
(In reply to comment #3) > (From update of attachment 184802 [details]) > Can we make a test that tries to construct a really big ImageBuffer? The attached test crashes CR (hitting the same generated image tiled draw path as the original page), but unfortunately it doesn't seem to trigger the same failure in DRT. I presume DRT runs with a different graphics context that handles surface allocations differently? Even ridiculous width/height values appear to "work": DRT doesn't crash, but the gradient is not drawn either (instead the visible portion is filled with a greenish color). Given this difference in behavior, I'm not sure how to produce a DRT test that isolates the bug. Any ideas?
Justin Novosad
Comment 6 2013-01-28 07:22:38 PST
> Given this difference in behavior, I'm not sure how to produce a DRT test that isolates the bug. Any ideas? Instead of testing in DRT, you could write a unit test (in trunk/Source/WebKit/chromium/tests/) that uses a fake PlatformContextSkia that fails allocations by design.
Mike Reed
Comment 7 2013-02-22 13:10:45 PST
I think this patch fixes https://code.google.com/p/chromium/issues/detail?id=177759
Mike Reed
Comment 8 2013-02-22 13:14:34 PST
#6 -- I don't know that that would be a stable test, since this webkit code is not really mockable. Do we have other such tests that exist to exercise a specific null-check failure? If not, perhaps we can land this CL as is.
James Robinson
Comment 9 2013-02-22 13:26:29 PST
Comment on attachment 184802 [details] Patch This seems reasonable.
WebKit Review Bot
Comment 10 2013-02-22 13:32:40 PST
Comment on attachment 184802 [details] Patch Clearing flags on attachment: 184802 Committed r143784: <http://trac.webkit.org/changeset/143784>
WebKit Review Bot
Comment 11 2013-02-22 13:32:44 PST
All reviewed patches have been landed. Closing bug.
Note You need to log in before you can comment on or make changes to this bug.