New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 123589 link

Starred by 23 users

Issue metadata

Status: Fixed
Last visit > 30 days ago
Closed: Apr 2012
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 1
Type: Compat

  • Only users with EditIssue permission may comment.

Sign in to add a comment

Facebook timeline crashes every time

Reported by, Apr 16 2012

Issue description

Chrome Version       : 18.0.1025.162
OS Version: OS X 10.7.3
URLs (if applicable) :
Other browsers tested:
  Add OK or FAIL after other browsers where you have tested this issue:
     Safari 5:
  Firefox 4.x:
     IE 7/8/9:

What steps will reproduce the problem?

going to facebook's timeline, crashes it every time

What is the expected result?

timeline view

What happens instead?

Aw, snap!  your page crashed.  Never happened with previous version of chrome.

Please provide any additional information below. Attach a screenshot if

UserAgentString: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_3) AppleWebKit/535.19 (KHTML, like Gecko) Chrome/18.0.1025.162 Safari/535.19

when going to facebooks timeline page, it crashes when scrolling down the page any amount.  Picture attached.  No new extensions since the update and it worked just fine with the last version.
Screen Shot 2012-04-16 at 9.39.05 AM.png
20.9 KB View Download

Comment 2 by, Apr 16 2012

Labels: Action-FeedbackNeeded
Thanks for the report. Is there a crash id to find at chrome://crashes ?

Thanks in advance.
Just enabled the reporting and allowed it to crash again.  Crash Id
 On Apr 16, 2012 12:59 PM, <> wrote:

Comment 4 by, Apr 16 2012

Labels: -Area-Undefined -Action-FeedbackNeeded Stability-Crash
Thanks for your feedback and the crash id !
Labels: Area-Compat
 Issue 123636  has been merged into this issue.
 Issue 123271  has been merged into this issue.

Comment 9 by, Apr 17 2012

 Issue 123724  has been merged into this issue.
Labels: -Pri-2 Pri-1
Status: Untriaged
Labels: Hotlist-ConOps
We've also received similar reports from users in the Chrome Help Forum about crashes  on Facebook's Timeline. Users have updated to 18.0.1025.163 but still get Aw, Snap crashes.

Users mention that the crash occurs when:
- simply scrolling in Timeline
- scrolling really fast in Timeline, and upon reaching a map/places, Chrome crashes
- zooming in on maps

Crash IDs: c55f781aab242b6d, 14c6217435513cc3

Mac OS 10.7.3

New Stack Signature:

Crash IDs: 1fbe03f631feac76

Mac OS 10.6.8

New Stack Signature: 

Help Forum Reference:!msg/chrome/vQOEHNtN9H0/0g9yEbe7chQJ
I don't have reproductions myself, but from what I've seen of stack traces slightly higher up we're running out of memory during Skia allocations when resizing images.

With a Timeline view of a heavy Facebook user open, it's not hard to get a renderer over 250MB, with 60k+ DOM nodes. Do we have any sense of whether the crash reports are from RAM-constrained computers?
@tomhudson, would capturing --full-memory-crash-report help diagnose this issue further?
 Issue 123746  has been merged into this issue.
Chrome crashes when zooming in on a Facebook Map or on the Places box when scrolling down a Facebook timeline. This happens every time. Started several days ago.

Crash ID 1fbe03f631feac76
Occurred Tuesday, April 17, 2012 4:22:57 AM

Memory 4GB 1067 MHz DDR3
MacBook Pro 17"
Processor: 2.93 GHz Intel Core 2 Duo
Os X 10.6.8

Comment 16 by, Apr 17 2012

Status: Assigned
Mike, we need some help with this. Any chance you can get someone to take a look asap! this can be related to major renderer crashes we see on Mac in m18 and m19.

Comment 17 by, Apr 17 2012

@mahoneyedit, thank you that's very helpful.  We are having a hard time reproducing this issue.  Would you mind helping us by answering a few more questions:

Is the crash more easy to reproduce on certain profiles?  Are there any profiles where it always happens?

Do you notice anything in particular about the profiles that seems to trigger the crash (e.g. they all have embedded maps)?

Big thanks in advance.
laforge@ pointed out that many of the non-Facebook sites with similar crashes are also using Bing maps.

It looks like Bing keeps a few "root" tiles of the world map in the DOM and scales them up 32x or more: if I zoom in just north of St. Louis, MO, I've got everything from Brazil north to the arctic circle in the DOM. That gives them a low-res fallover while loading detailed nearground tiles. It shouldn't be happening, but if we were allocating those at full res that'd add a quarter-gig per map.

it seems to happen every time on my profile and i do believe there is some sort of map on there.  May be the trigger, not sure if i can remove it though..

This consistently repros for me:
1 Go to
2 Click outside the map to make sure the map doesn't have focus for step 4
3 Hit CMD-0 to bring yourself back to the default zoom
4 Hit CMD-+ to zoom in one level on Chrome
5 Zoom all the way out on the map. Hit the map's zoom-in button 8 times to bring you to the 9th zoom level
6 Chrome should crash at this point

I am running Chrome 18.0.1025.163 on Mac OS X 10.7.3.

As far as I can tell, Chrome crashes every time I go to a friends map and zoom in by selecting a point of interest. It's usually a big jump from a map of the whole earth in to city level. 

The map zoom-in crash seems to be consistent on all profiles. Except sometimes I can zoom in two steps before chrome crashes and some maps crash immediately without even zooming. 

I only had one friends timeline where it crashed chrome while scrolling. It had a "places" box on the timeline and as it became visible on the screen by scrolling down the timeline chrome would crash. They have since removed the places box and I can't reproduce that crash.

It has at times also crashed several tabs at once, some with facebook & others with non facebook pages that didn't have Bing either. But it probably had flash or some other plug-in. But I have not been able to reproduce that crash.

Hope that helps

Comment 22 by, Apr 18 2012

This seems to be caused by bad caching behavior when upscaling a small subsection of an image by a large factor. Skia decides to upscale and cache the entire image, which is too big. Possible patch attached.
1.3 KB View Download

Comment 23 by, Apr 18 2012

@groby, IANAR but looks good to me.

Comment 25 by, Apr 18 2012

Upstream WebKit bug

@22: There's already some code in WebCore/platform/image-decoders/ImageDecoder.h to catch oversized images for overflow prevention -- see isOverSize().  Does that check prevent the cases that would otherwise lead to overflow in your patch?  If not, maybe we should make this public or in some other way accessible elsewhere so we can reuse it where you need it?

Comment 27 by, Apr 18 2012

Yep, isOverSize would do the trick too. I'll copy that code over once I got my WK patch ready to go. (Unless you've got a good place where it can be made accessible by both - but even then, I'd rather do that as a second refactor so we can land the crash fix ASAP)

Comment 28 by, Apr 18 2012

Labels: Merge-Requested Mstone-19
Landed in WK as r114487: <>

Comment 29 by, Apr 18 2012

Labels: -Merge-Requested Merge-Approved

Comment 30 by, Apr 18 2012


Comment 31 by, Apr 18 2012

Big big thanks to Rachel!  Awesome work.
Does this mean that the next Chrome update will fix this crashing error or am I jumping the gun?
It looks like this change missed today's Canary? In that case, tomorrow's Chrome 20 Canary will have the fix (assuming we get a WebKit roll in today). "Merge-Approved" above means Chrome 19 Beta should get this fix in a few days.

If the change were to be propagated to Chrome 18, it would normally only be after we've seen it live in Canary and Beta for several days so that we have some confidence in it, so it could be a couple of weeks or longer before this gets to Chrome Stable.

Comment 34 by, Apr 18 2012

merged into 1025, as well.
@27: I would first check whether the isOverSize() check eliminates all possible cases where the code you touched could overflow.  If it does you could just ASSERT that the sizes are small enough here, and comment as to why that assertion holds.

If it doesn't guarantee this, then there are various possibilities; one is to make it a public static function instead of private, so you can call it from elsewhere; another is to see if there's some other place in the call chain we should be checking for overflow that eliminates the possibility of overflow in both existing spots.

All this is really my way of saying "please make the most comprehensive-but-simple fix, whatever that is, and don't just copy the code" :)
 Issue 123505  has been merged into this issue.
 Issue 119031  has been merged into this issue.
This is working fine on the latest M18 build 18.0.1025.165 - Mac osx 10.6.8 & 10.7

Comment 39 by, Apr 26 2012

Status: Fixed
Per the comment above, this is fixed in the latest Stable update (18.0.1025.165) on Mac. Closing.

Comment 40 by Deleted ...@, Apr 30 2012

Huh Fixed?

I have 18.0.1025.165 and it's even worse then it used to be. Now everytime you have Facebook open it will just crash chrome completely and while you can open new windows/tabs it won't load them and just give you a blank page. The only way to get it working again is to force quit chrome then open a new window without leaving Facebook open in a tab. 

It's pretty annoying when you try to click on a link in your timeline as it crashes every damn time. I've tried it on 2 macs (both 8gb ram, one iMac and a MPB) and have the exactly the same problem.

Comment 41 by, Aug 8 2012

Labels: -Merge-Approved
Removing Merge-Approved from past milestones.
Project Member

Comment 42 by, Oct 13 2012

Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Project Member

Comment 43 by, Mar 10 2013

Labels: -Type-Bug -Area-Compat -Mstone-19 Type-Compat M-19
Project Member

Comment 44 by, Mar 13 2013

Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue

Sign in to add a comment