Bug 98456 - [chromium] Crash in WebCore::GraphicsLayerChromium::setContentsToImage
Summary: [chromium] Crash in WebCore::GraphicsLayerChromium::setContentsToImage
Alias: None
Product: WebKit
Classification: Unclassified
Component: Layout and Rendering (show other bugs)
Version: 528+ (Nightly build)
Hardware: All Unspecified
: P2 Normal
Assignee: Nobody
URL: http://code.google.com/p/chromium/iss...
Depends on:
Blocks: 99207
  Show dependency treegraph
Reported: 2012-10-04 15:17 PDT by Nick Carter
Modified: 2012-10-12 14:05 PDT (History)
7 users (show)

See Also:

Patch (4.78 KB, patch)
2012-10-04 15:30 PDT, Nick Carter
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Nick Carter 2012-10-04 15:17:20 PDT
GraphicsLayerChromium::setContentsToImage does not handle a null return from nativeImageForCurrentFrame().

This can happen if there is an error early in the decoding of an image. I have a layout test that demonstrates the crash, and a proposed fix.
Comment 1 Nick Carter 2012-10-04 15:30:19 PDT
Created attachment 167188 [details]
Comment 2 James Robinson 2012-10-05 15:14:53 PDT
Comment on attachment 167188 [details]

R=me. Thanks for tracking this down!
Comment 3 Abhishek Arya 2012-10-05 15:18:18 PDT
Note that null ptr crashes are not security bugs. Please don't use the security template for such bugs in the future.
Comment 4 Nick Carter 2012-10-05 15:20:53 PDT
@inferno -- that's what I thought, but I figured I'd rather be wrong in this direction than in the other direction.
Comment 5 Abhishek Arya 2012-10-05 15:22:23 PDT
(In reply to comment #4)
> @inferno -- that's what I thought, but I figured I'd rather be wrong in this direction than in the other direction.

Feel free to poke us anytime on chat :)
Comment 6 WebKit Review Bot 2012-10-05 15:25:48 PDT
Comment on attachment 167188 [details]

Rejecting attachment 167188 [details] from commit-queue.

nick@chromium.org does not have committer permissions according to http://trac.webkit.org/browser/trunk/Tools/Scripts/webkitpy/common/config/committers.py.

- If you do not have committer rights please read http://webkit.org/coding/contributing.html for instructions on how to use bugzilla flags.

- If you have committer rights please correct the error in Tools/Scripts/webkitpy/common/config/committers.py by adding yourself to the file (no review needed).  The commit-queue restarts itself every 2 hours.  After restart the commit-queue will correctly respect your committer rights.
Comment 7 WebKit Review Bot 2012-10-05 15:57:13 PDT
Comment on attachment 167188 [details]

Rejecting attachment 167188 [details] from commit-queue.

Failed to run "['/mnt/git/webkit-commit-queue/Tools/Scripts/webkit-patch', '--status-host=queues.webkit.org', '-..." exit_code: 2

Last 500 characters of output:

Auto-merging Source/WebCore/ChangeLog
CONFLICT (content): Merge conflict in Source/WebCore/ChangeLog
Failed to merge in the changes.
Patch failed at 0001 Try to fix the build.

When you have resolved this problem run "git rebase --continue".
If you would prefer to skip this patch, instead run "git rebase --skip".
To restore the original branch and stop rebasing run "git rebase --abort".

rebase refs/remotes/origin/master: command returned error: 1

Died at Tools/Scripts/update-webkit line 164.

Full output: http://queues.webkit.org/results/14183550
Comment 8 WebKit Review Bot 2012-10-07 15:13:55 PDT
Comment on attachment 167188 [details]

Clearing flags on attachment: 167188

Committed r130610: <http://trac.webkit.org/changeset/130610>
Comment 9 WebKit Review Bot 2012-10-07 15:13:58 PDT
All reviewed patches have been landed.  Closing bug.
Comment 10 Simon Fraser (smfr) 2012-10-08 11:03:15 PDT
The ref test is failing on Mac.
Comment 11 James Robinson 2012-10-08 12:12:01 PDT
What does the failure look like?
Comment 12 Simon Fraser (smfr) 2012-10-08 12:36:51 PDT
The partial image is black. This is probably an OS-level thing.
Comment 14 Nick Carter 2012-10-09 13:58:55 PDT
The reftest is based on the assumption that a broken image will render the same regardless of whether or not it has an identity transform applied (in this case, a z-transform of zero). If that assumption is invalid for the Mac port, we can change this test so that it's not a reftest -- all I really needed was a "doesn't crash" expectation; making it a reftest was gravy.

Please let me know if you'd like me to relax the test in that way.
Comment 15 Simon Fraser (smfr) 2012-10-09 15:16:34 PDT
Yes, you should change the test. A 'do not crash' test should never be a ref test anyway, because those are more expensive to run.

The new test can use internals.layerTreeAsText() to verify that the image is going into a compositing layer.
Comment 16 Simon Fraser (smfr) 2012-10-09 15:16:55 PDT
Oh, and we should have a separate bug on the fact that the image is black on Mac.
Comment 17 Simon Fraser (smfr) 2012-10-10 21:23:45 PDT
It's bad to leave the test failing for so long. I'm gonna make it an ImageOnlyFailure in Mac TestExpectations.
Comment 18 Simon Fraser (smfr) 2012-10-10 21:26:05 PDT