Bug 190954 - CRASH in CoreGraphics: ERROR_CGDataProvider_BufferIsNotBigEnough
Summary: CRASH in CoreGraphics: ERROR_CGDataProvider_BufferIsNotBigEnough
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Jer Noble
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2018-10-26 05:18 PDT by Jer Noble
Modified: 2018-10-29 12:08 PDT (History)
12 users (show)

See Also:


Attachments
Patch (13.29 KB, patch)
2018-10-26 07:03 PDT, Jer Noble
no flags Details | Formatted Diff | Diff
Patch (15.51 KB, patch)
2018-10-26 07:38 PDT, Jer Noble
no flags Details | Formatted Diff | Diff
Patch for landing (20.67 KB, patch)
2018-10-29 10:14 PDT, Jer Noble
no flags Details | Formatted Diff | Diff
Patch for landing (22.69 KB, patch)
2018-10-29 10:53 PDT, Jer Noble
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jer Noble 2018-10-26 05:18:26 PDT
CRASH in CoreGraphics: ERROR_CGDataProvider_BufferIsNotBigEnough
Comment 1 Jer Noble 2018-10-26 07:03:13 PDT
Created attachment 353182 [details]
Patch
Comment 2 Jer Noble 2018-10-26 07:38:55 PDT
Created attachment 353184 [details]
Patch
Comment 3 Jer Noble 2018-10-26 08:26:45 PDT
<rdar://problem/45492021>
Comment 4 Simon Fraser (smfr) 2018-10-26 22:28:18 PDT
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?
Comment 5 Jer Noble 2018-10-27 12:46:53 PDT
(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.
Comment 6 Jer Noble 2018-10-27 12:49:38 PDT
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.
Comment 7 Simon Fraser (smfr) 2018-10-27 23:40:48 PDT
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?
Comment 8 Jer Noble 2018-10-29 06:24:40 PDT
(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.
Comment 9 Jer Noble 2018-10-29 10:14:27 PDT
Created attachment 353295 [details]
Patch for landing
Comment 10 Jer Noble 2018-10-29 10:53:24 PDT
Created attachment 353299 [details]
Patch for landing
Comment 11 WebKit Commit Bot 2018-10-29 12:08:31 PDT
Comment on attachment 353299 [details]
Patch for landing

Clearing flags on attachment: 353299

Committed r237559: <https://trac.webkit.org/changeset/237559>
Comment 12 WebKit Commit Bot 2018-10-29 12:08:33 PDT
All reviewed patches have been landed.  Closing bug.