My favorites | Sign in
Project Home Downloads Wiki Issues Code Search
New issue   Search
for
  Advanced search   Search tips   Subscriptions
Issue 89585: System hang upon opening a new tab
5 people starred this issue and may be notified of changes. Back to list
Status:  IceBox
Owner:  ----
Closed:  Aug 2012

Restricted
  • Only users with Commit permission may comment.


Sign in to add a comment
 
Reported by miika.ah...@gmail.com, Jul 18, 2011
On some random occasions, Chrome and my system hangs when I open a new tab (regardless of how, such as simple new tab or open link in new tab).

All I can tell about it is that the Window with the tab becomes completely unoperable, the process responsible for that tab/window each one of my CPU cores completely, and my computer becomes overall extremely unresponsive.

This continues for ever as far as I can tell, though I haven't really tested that. The longest I've let it churn about is about half an hour, so I don't think it was about to solve it on its own. The problem disappears as soon as I kill the Chrome process that does this.

In task manager, the I/O counters remain unchanged, number of threads remains unchanged, handles remains unchanged, and on my last attempt I enabled display of other statistics and saw that the hanging process used 10000 GDI objects. That's not normal I think. So I presume it was extremely aggressively trying to create new ones even when it had hit some sort of hard limit for them and thus hanging itself and OS?

Anyway, I lose the tabs in that window each time, they don't appear in recently opened pages or anything because of the need to kill the process.

This happens on Windows 7, and after looking around, Vista would suffer from it too at the same point ( http://msdn.microsoft.com/en-us/library/ms724291(v=vs.85).aspx ).

Another point, most apps, even Chrome, normally uses at most 4000-5000 GDI objects and even that is somewhat rare.
Jul 18, 2011
#1 miika.ah...@gmail.com
"the process responsible for that tab/window each one of my CPU cores completely"
... eats, not each
Aug 1, 2011
#2 Branding...@gmail.com
I'm having a similar problem. Sometimes when I open a new tab and type in the address bar whether it be google.com or searching, such as typing in the address bar "puppies"... the page hangs. It's unresponsive. I think this may be related...
Sep 30, 2011
#3 nigel.l....@gmail.com
I'm getting the same issue. "chromedeck" often seems to cause it. I have ati/intel switchable graphics on a Lenovo W500 running W7 x64. I can guess it could be a gpu driver issue, but the effect is massive. System takes many minutes to even get a task list. CTRL-ALT-DEL can fail to respond. Only once I tried to debug properly, and that took hours. Something running very high priority in the kernel.


Nov 1, 2011
#4 miika.ah...@gmail.com
This seems to happen a lot more rapidly on occasion since the last update to Chrome, upon opening some pages (Wikipedia's front page surprisingly frequently though it's not the only one) the GDI object count skyrockets from less than 200 up to 10,000 (I had task manager open during one of these to see it). Killing the process solves this quickly but repeats almost immediately if I don't close the whole session and start again.
Nov 1, 2011
#5 miika.ah...@gmail.com
The summary of this issue should be "system hang from GDI object starvation" or something instead of the current new tab one.
Nov 1, 2011
#6 yosin@chromium.org
Hi miika, could you tell me WIkipedia URI you saw lots of GDI objects usage?
I tried on 
* http://en.wikipedia.org/wiki/Main_Page English
* http://ja.wikipedia.org/wiki/Main_Page Japanese
But, number of GDI objects is 49(render process), 341(browser process).

If you have a chance, please try to use GDIView or another tool to show details of GDI object count.
  http://www.nirsoft.net/utils/gdi_handles.html

Thanks in advance.
Nov 10, 2011
#7 the...@gmail.com
This happens frequently to me too. I've learned to recognize the symptoms and start Task Manager fast enough to be able to kill the offending Chrome process before it gets too bad. (Not that I really enjoy having had to learn that, mind.) The GDI object count ends up being 10,000 (I guess that's some hard-coded maximum per process in Windows.)

However just now this bug pretty much took down the whole OS, with no other program able to do its thing, nor did W7's CTRL+ALT+DEL screen work.

As a workaround until this can be fixed for good, would it be possible to add a watchdog sort of system that would kill Chrome processes that use over >6000 GDI objects?

Chrome 17.0.932.0
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
Graphics card: Geforce GTX 460, driver version 280.26
Nov 11, 2011
#8 the...@gmail.com
I ended up writing a quick hack of a watchdog in C# myself.
Not sure if it works... hoping I don't have a chance to find out :-).

Source and binary available on Bitbucket, https://bitbucket.org/akx/chromeguard/overview
Nov 11, 2011
#9 miika.ah...@gmail.com
Haven't had the problem for at least two days now. I'm using bet beta releases btw and currently using 16.0.912.21 beta-m (which apparently is outdated again). The highest GDI count has been ~1500 for a while and currently it seems to be mostly fonts with ~20 DCs and bitmaps each (according to gdiview). And I meant the www.wikipedia.org as the one causing the GDI spike, before I even selected which language of their site I'd use.

I'll see if I can somehow coax something to happen for this, though currently it seems the problem has gone into hiding.
Aug 10, 2012
#10 bugdro...@chromium.org
Closing old bug as obsolete. Please file a new bug (with details) if this problem is still occurring for you.
Status: IceBox
Aug 21, 2012
#11 rpmussel...@gmail.com
Same problem.  But if you open a new tab next to the frozen tab, the frozen tab unfreezes.  Try it.  Not a perfect solution but it works.
Oct 13, 2012
#12 bugdro...@chromium.org
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.
Labels: Restrict-AddIssueComment-Commit
Mar 10, 2013
#13 bugdro...@chromium.org
(No comment was entered for this change.)
Labels: -Area-Undefined
Sign in to add a comment

Powered by Google Project Hosting