On the mac platform, when we build with ENABLE(PURGEABLE_MEMORY), the call SharedBuffer::buffer() can return an empty vector when the SharedBuffer contains no data, but has purgeable memory associated with it. Some image decoders (JPEGImageDecoder & WEBPImageDecoder) rely on buffer() to get their data, and as a result are actually broken after the original image data has migrated to purgeable memory. This migration occurs on Images in CachedImage::destroyDecodedData(), which makes JPEG and WEBP images unreconstructable by the JPEGImageDecoder after we've destroyed the decoded data, a very undesirable result, as subsequent decode attempts get a 0,0 image.
Created attachment 82382 [details] Patch
Comment on attachment 82382 [details] Patch Image parts LGTM
Comment on attachment 82382 [details] Patch This patch fixes the issue by removing consumers of SharedBuffer::buffer() and using the safer SharedBuffer::data(). pkasting pointed out (in irc) that there may be further simplification to be had by making all decoders use the same interface. I believe that! However this bug was causing chrome to stop displaying images on many sites, and so I made this minimal fix right away. I'm open to ideas on testing, and also to follow up with more rationalization of how we handle SharedBuffer. See: http://code.google.com/p/chromium/issues/detail?id=68622 for the chrome bug that brought me here.
Comment on attachment 82382 [details] Patch r=me
The commit-queue encountered the following flaky tests while processing attachment 82382 [details]: http/tests/websocket/tests/multiple-connections.html bug 53825 (author: abarth@webkit.org) The commit-queue is continuing to process your patch.
Comment on attachment 82382 [details] Patch Clearing flags on attachment: 82382 Committed r78548: <http://trac.webkit.org/changeset/78548>
All reviewed patches have been landed. Closing bug.
Renaming this bug (a bit late!) at ap's suggestion.
Shame the changelog didn't say anything about the changes.