Bug 170912

Summary: [iOS, macOS] Guard against passing nullptr to vImagePremultiplyData
Product: WebKit Reporter: Brent Fulgham <bfulgham>
Component: WebCore Misc.Assignee: Brent Fulgham <bfulgham>
Status: RESOLVED FIXED    
Severity: Normal CC: beidson, bfulgham, ddkilzer, dino, sabouhallawa, zalan
Priority: P2 Keywords: InRadar
Version: WebKit Nightly Build   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
Patch
none
Patch beidson: review+

Description Brent Fulgham 2017-04-17 13:35:27 PDT
If the system is under heavy memory pressure, it is possible for a calloc to fail, resulting in an ImageBuffer with a nullptr data member.

We should return from an attempt to perform ImageBuffer::putData on a nullptr without taking any action, or perhaps RELEASE_ASSERT that we encountered this case.

Since the memory pressure may be transient, it seems reasonable to just bail out early; a future attempt may succeed.
Comment 1 Brent Fulgham 2017-04-17 13:38:05 PDT
Created attachment 307292 [details]
Patch
Comment 2 Brent Fulgham 2017-04-18 13:12:55 PDT
<rdar://problem/30565800>
Comment 3 Brady Eidson 2017-04-18 16:59:42 PDT
Comment on attachment 307292 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=307292&action=review

> Source/WebCore/platform/graphics/cg/ImageBufferDataCG.cpp:444
> +        ASSERT(data);
> +        if (!data)
> +            return;

We can't really both expect that is' impossible to have a null data (like the assert says) but also expect it is possible to have a null data (like the early return says)

If it's truly impossible, we need to know why.

If it's truly possible (such as we commonly get into the case where memory can't be allocated), then the ASSERT should be dropped.
Comment 4 Brent Fulgham 2017-04-18 17:16:58 PDT
Comment on attachment 307292 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=307292&action=review

>> Source/WebCore/platform/graphics/cg/ImageBufferDataCG.cpp:444
>> +            return;
> 
> We can't really both expect that is' impossible to have a null data (like the assert says) but also expect it is possible to have a null data (like the early return says)
> 
> If it's truly impossible, we need to know why.
> 
> If it's truly possible (such as we commonly get into the case where memory can't be allocated), then the ASSERT should be dropped.

Good point. I'll revise.
Comment 5 Brent Fulgham 2017-04-18 17:17:02 PDT
Created attachment 307439 [details]
Patch
Comment 6 Brent Fulgham 2017-04-19 09:17:55 PDT
Committed r215514: <http://trac.webkit.org/changeset/215514>