Bug 170912 – [iOS, macOS] Guard against passing nullptr to vImagePremultiplyData

• Status: RESOLVED
• Resolution: FIXED
• Component: WebCore Misc.

[Brent Fulgham]

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.

[Brent Fulgham]

Created attachment 307292 [details]
Patch

[Brent Fulgham]

<rdar://problem/30565800>

[Brady Eidson]

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.

[Brent Fulgham]

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.

[Brent Fulgham]

Created attachment 307439 [details]
Patch

[Brent Fulgham]

Committed r215514: <http://trac.webkit.org/changeset/215514>