CRASH in CoreGraphics: ERROR_CGDataProvider_BufferIsNotBigEnough

• Component: New Bugs
• Status: RESOLVED FIXED

[Jer Noble]

CRASH in CoreGraphics: ERROR_CGDataProvider_BufferIsNotBigEnough

[Jer Noble]

Created attachment 353182 [details]
Patch

[Jer Noble]

Created attachment 353184 [details]
Patch

[Jer Noble]

<rdar://problem/45492021>

[Simon Fraser (smfr)]

Comment on attachment 353184 [details]
Patch

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

> Source/WebCore/ChangeLog:17
> +        (This assumes that the issue is the wrong sized buffer at CGDataProvider creation time, and not
> +        that the buffer itself is reclaimed between creation time and access.)

Isn't this the more likely scenario?

[Jer Noble]

(In reply to Simon Fraser (smfr) from comment #4)
> Comment on attachment 353184 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=353184&action=review
> 
> > Source/WebCore/ChangeLog:17
> > +        (This assumes that the issue is the wrong sized buffer at CGDataProvider creation time, and not
> > +        that the buffer itself is reclaimed between creation time and access.)
> 
> Isn't this the more likely scenario?

We have absolutely no way of knowing. At least with this patch in place, we have narrowed the possibilities.

[Jer Noble]

Oh, and to continue the thought, previous crashes in other projects with this same stack trace were due to miscalculations in row size, etc. Not due to premature release.

[Simon Fraser (smfr)]

Comment on attachment 353184 [details]
Patch

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

> Source/WebCore/platform/graphics/cg/ImageUtilitiesCG.h:32
> +inline uint8_t verifyImageBufferIsBigEnough(const void* buffer, size_t bufferSize)

This function isn't really specific to image buffers so the filename seems oddly specific, but hopefully it's temporary.

> Source/WebCore/platform/graphics/cg/ImageUtilitiesCG.h:40
> +    return *(uint8_t*)lastByte;

Might the compiler optimize that away since no callers use the return value?

[Jer Noble]

(In reply to Simon Fraser (smfr) from comment #7)
> Comment on attachment 353184 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=353184&action=review
> 
> > Source/WebCore/platform/graphics/cg/ImageUtilitiesCG.h:32
> > +inline uint8_t verifyImageBufferIsBigEnough(const void* buffer, size_t bufferSize)
> 
> This function isn't really specific to image buffers so the filename seems
> oddly specific, but hopefully it's temporary.

Indeed. In the meantime, I at least renamed the file "ImageBufferUtilitiesCG.h"

> > Source/WebCore/platform/graphics/cg/ImageUtilitiesCG.h:40
> > +    return *(uint8_t*)lastByte;
> 
> Might the compiler optimize that away since no callers use the return value?

I talked this over with Keith and Alex and the consensus was that it would. Without crazy #pragma magic, the best way to avoid this would be to put it into its own translation unit, so move the implementation into a .cpp file and do /not/ add it to the unified build system. I'll do that before landing.

[Jer Noble]

Created attachment 353295 [details]
Patch for landing

[Jer Noble]

Created attachment 353299 [details]
Patch for landing

[WebKit Commit Bot]

Comment on attachment 353299 [details]
Patch for landing

Clearing flags on attachment: 353299

Committed r237559: <https://trac.webkit.org/changeset/237559>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.