Issue metadata
Sign in to add a comment
|
This gif (attached) breaks any web page
Reported by
daniel.m...@gmail.com,
Feb 28 2016
|
||||||||||||||||||||||
Issue descriptionChrome Version Versión 48.0.2564.116 m : <from About Google Chrome/Chromium or 'about:version'> URL : http://monclus.pasfer.com/Chrome_crack.htm Behavior in Safari 4.x/5.x: Behavior in Firefox 3.x/4.x: What steps will reproduce the problem? 1. access the website 2. 3. GIF attached and in http://monclus.pasfer.com/BadGif.gif No se si entendéis español, pero por si acaso, este GIF si lo pones como avatar en un Foro, lo destrozas en chromae Saludos
,
Mar 17 2016
in chrome 32bits. Chrome 64 is OK
,
Mar 17 2016
Thank you for providing more feedback. Assigning to requester "brajkumar@chromium.org" for another review. For more details visit https://sites.google.com/a/chromium.org/dev/issue-tracking/autotriage - Your friendly Sheriffbot
,
Apr 28 2016
Requesting Bibin to try a repro in 32 bit chrome.
,
Apr 28 2016
Sorry, i don't understand "bibin".
,
May 2 2016
Able to reproduce the issue on Windows 7 using chrome latest stable M50-50.0.2661.94 (32 bit). Observed the page crashes while loading http://monclus.pasfer.com/Chrome_crack.htm Bisect Information: ===================== Good build: 42.0.2276.0 Bad Build : 42.0.2278.0 Change Log URL: https://chromium.googlesource.com/chromium/src/+log/fa28471eb5b20de1c8ec4f3fb06f72e68c5bda0d..73f4cdc4af163550f8a0188611f1b8b00602bd95 Blink Log URL: https://chromium.googlesource.com/chromium/blink/+log/a705d7d..8f441d9 From the above blink log suspecting below change Review URL: https://codereview.chromium.org/813943003 hclam@ - Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner. Thanks!
,
May 2 2016
It seems likely that the suspected CL has something to do with the issue in question (probably OOM because of a large frame size due to frame offset). AFAIK though hclam@ is no longer in the project. Punting to more appropriate label for triage.
,
May 2 2016
> It seems likely that the suspected CL has something to do with the issue in question > (probably OOM because of a large frame size due to frame offset). FWIW, although that CL may or may not cause this problem for that particular image (I haven't tested without that CL, which was submitted over a year ago, and arguably results in better behavior for some broken GIFs - side note: the reporter in issue 509437 argues that this is *not* better behavior), the real general problem is that we crash if we try to allocate too large of an image. So although this particular GIF may have a screen size small enough to work, but the first frame expands that to be too larger, you could imagine a similar GIF with a giant screen size. We have a number of bugs in this area (see issue 527765, issue 599087, issue 509437 , issue 391878 ...). Although this was the intended behavior (ironically, ImageFrame::setSize [1] attempts to gracefully handle too large of an allocation by returning false, but the method it calls to allocate may deliberately crash), we have been thinking about ways to handle it better. [1] https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/platform/image-decoders/ImageFrame.cpp&sq=package:chromium&rcl=1462173394&l=103
,
Jun 1 2016
Moving this nonessential bug to the next milestone. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jun 20 2016
|
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by brajkumar@chromium.org
, Mar 2 2016Labels: Needs-Feedback
9.1 KB
9.1 KB View Download
28.4 KB
28.4 KB View Download