Ok, got some extra info about this issue:
The initial empty tooltip won't make chrome hang, but, after hovering over anything that would create one of these, the new tooltip will.

I got this on my journal from killing chrome when it got unresponsible and the WM offered the option:

Jun 24 19:22:52 mateus-arch gnome-session[1751]: Aviso do gerenciador de janelas: last_focus_time (26100080) is greater than comparison timestamp (26100078).  This most likely represents a buggy client sending inaccurate timestamps in messages such as _NET_ACTIVE_WINDOW.  Trying to work around...
Jun 24 19:22:52 mateus-arch gnome-session[1751]: Aviso do gerenciador de janelas: Log level 16: STACK_OP_RAISE_ABOVE: sibling window 0x2200009 not in stack

@charles.costar,
Thanks for your report.  Could you update Chrome with the latest build and check the issue on it.  And, also, provide the URL which has the issue.

I can still reproduce this on 38.0.2096.0.

Some extra info I got after experiencing this a lot of times:

I noticed that this generally happens when, at the same time Chrome tries to create a tooltip, the system is slow due to doing some heavy processing somewhere (e.g. Navigating through lots of tabs on Chrome itself).
When this happens, the first blank tooltip is created but I can still use Chrome without any problems.
However the next tooltip is also blank and, after it is created, no Chrome window receives any of my input.

Every time this bug happens I have no other choice except to close Chrome, generally I do that when the first tooltip happens as it is easier. Could you make it a higher priority, ReleaseBlock or something else?

I'm confirming this with 38.0.2101.0 on Fedora 20 x64.

Just as in comment #4 I have noticed this happening under heavy loads.  If the bug proves difficult to reproduce, I'd be happy to run a debug/assert build and try to gather some stack traces.

Anyway, safe to say that this is incredibly annoying, especially on slightly older hardware.  IMHO, this needs a higher priority, as well as a fix for the M37 branch.

Today I managed not only to trigger this bug once, but also to trigger it a few moments later, after restoring the same session. I had a tab running flash, some Youtube videos and some normal pages.
Perhaps the heavy load from restoring a session is a good way to trigger it?
Version 38.0.2101.0 here too.

Slowing down the browser using a GMail tab and a 1080p Youtube (HTML5) video, I was able to reproduce this more reliably.  I managed to do a bisect, giving me the range r273013-r273070. [1]

Especially r273014 looks suspicious. [2]  Hopefully someone can use this to find a cause and a fix?

[1] http://build.chromium.org/f/chromium/perf/dashboard/ui/changelog.html?url=%2Ftrunk%2Fsrc&range=273013%3A273070&mode=html

[2] http://src.chromium.org/viewvc/chrome?revision=273014&view=revision

Still happens with 38.0.2121.3 dev.

I finally managed to get a stack trace for this hang (attached).  Version is  39.0.2128.0 (290252) (64-bit)

It looks like BlockUntilWindowMapped never returns.

Based on the stack trace (and the movie in the other bug report) issue 403194 is a duplicate.

hang-stack.txt 6.5 KB View Download

I'm having exactly the same issue with Chrome 37.0.2062.94 (64-bit) on Ubuntu 14.04.1 LTS (Gnome 3.12.2) since almost two weeks.
It's really really annoying as the only option is terminating the whole process.

Issue 403194 has been merged into this issue.

Stack trace provided in Comment 10.

How I reproduce this bug all the time:

1. Create several bookmark folders.
2. Fill them with some content.
3. Arrange the folders on the bookmark bar in one contiguous line.
4. Click on a random folder to pop a list.
5. Continuously move the mouse over all the folders.

The faster you move, the sooner the UI will freeze.

Too bad it still appears in the latest version :(

I thought stable is meant to be stable. Or maybe support for linux is abandoned? So many issues in GNOME for the last two years...

Any change of changing to a higher Pri or assigning it to someone?
Seriously, this bug makes it hard to open too many tabs. Restoring them, because of the hang made me close them, is even harder.

I am also experiencing this issue on Fedora 20 and GNOME 3.12. I had this on Chrome Stable 64-bits 37 and now on 38.

I get this every time I hover the mouse cursor on one of the bookmark bar entries and I can see the empty tooltip on different workspaces.

I don't notice increase in disk or CPU activity.

How can I create a stack trace?

Someone with commit access has to care about this, stack trace or not (stack trace is in comment 10). GNOME 3.12 might be too "new" to affect most people and that's why it's not being noticed.  Can anyone confirm whether it still occurs in GNOME 3.14?

Still experiencing this with Chrome 38.0.2125.101 (64-bit) on GNOME 3.12.2 / Ubuntu 14.04.1.

I'm now really thinking about switching back to Firefox, after about 5 years of Chrome...

After switching to Gnome 3.14 I haven't noticed this bug again.

@22 I've been suspecting the xserver here.  What version of X are you running?

I'm using Debian sid.

ii  xserver-xorg                          1:7.7+7                             amd64        X.Org X server
ii  xserver-xorg-core                     2:1.16.1-1                          amd64        Xorg X server - core server

Regularly hitting this on fedora 20 + gnome 3.12, on chrome 38 and 39.

$ rpm -qa | grep -i x.*server
xorg-x11-server-common-1.14.4-11.fc20.x86_64
xorg-x11-server-Xorg-1.14.4-11.fc20.x86_64
xorg-x11-server-utils-7.7-6.fc20.x86_64
xorg-x11-server-devel-1.14.4-11.fc20.x86_64

Still happening with Chrome 38.0.2125.101 (64-bit) / Gnome 3.12.1 
Kernel: 3.16.4-1-ARCH
$ paclocs xorg | grep server
local/xorg-server 1.16.1-1 (xorg)
local/xorg-server-common 1.16.1-1
local/xorg-server-utils 7.6-4

Issue 415928, Issue 414057 and Issue 415903 are duplicates of this.

Everybody seems to agree this is Gnome 3.12 fault and that it doesn't happen after update to 3.14.
I also noticed that steam and android-studio also create artifacts sometimes. But only chrome becomes unresponsive because of them.

Wrong, I happens with 3.14 too, even on Wayland.

> Everybody seems to agree this is Gnome 3.12 fault and that it doesn't happen after update to 3.14.

Maybe maybe, I can't create good highload with chrome because chrome crash because open many files.

And GPU acceleration not working :(
GpuProcessHostUIShim: The GPU process crashed!

Here a good way to create some nice load that leads to the problem is starting a couple of VMs with VirtualBox or Vagrant.

On my computer (i7-4700HQ - mobile) it doesn't matter if the VMs are actually doing something, just having them there (standard debian install) is enough.

Issue 415903 has been merged into this issue.

Issue 414057 has been merged into this issue.

Issue 415928 has been merged into this issue.

I hope I accurately portrayed the issue with this summary.

After switching to Gnome 3.14 on Fedora 21 and different hardware (Haswell, previously Core 2), the problem did not occur anymore for about 2 weeks.

I'm also not sure whether this is really related to high system load: in another bug, somebody reported being able to reliably trigger the bug when playing several YouTube videos while moving the cursor up and down a bookmark menu to create lots of tooltips. This approach did not work for me, the crashes I observed seemed to occur randomly.

All the freezes I noticed happened while I was using the mouse wheel to
scroll through pages where a hyperlink ended up under my mouse cursor.
There was never heavy load, unless watching a youtube movie counts.

No heavy load necessary for encountering this for me either. The other bug merged in this did not reference heavy load. Scrolling or hovering with the mouse is enough to make the stuck white tooltip appear. A crash then happens, sooner than later.

Same thing happens to me under Enlightenment 0.19.0 and Arch linux and latest chromium (currently chromium 38.0.2125.104). 
What's more, it does NOT happen under Enlightenment E16.

Chrome 40.0.2194.2 dev (64-bit) on Arch Linux.
gnome-shell 3.14.1-1, xorg-server 1.16.1-1

I haven't seen this for a while.

Confirming that this problem no longer occurs for me.

Chrome 38.0.2125.104 (64-bit) on Debian jessie
gnome 3.14.0
xserver 1.16.1

I have this same problem with Google Chrome on Gnome Shell 3.12.

I'm on Fedora 20 (64-bit)
Gnome 3.12.2
Google Chrome 38.0.2125.111 (64-bit)
Linux 3.16.6-200.fc20.x86_64
x86_64

Upgrading to Gnome 3.14 solved this issue for me as well.

2 days ago I made a clean install of Ubuntu GNOME 14.10 with Gnome Shell 3.12 and have not met this issue yet. 

> 2 days ago I made a clean install of Ubuntu GNOME 14.10 with Gnome Shell 3.12 and have not met this issue yet. 

No! It's happened again. Can't switch to Gnome Shell 3.14 because keyboard layout changing is not working for me there :(.

This isn't limited to Gnome, another user and I have experienced it in Enlightenment.

https://phab.enlightenment.org/T1759

Name           : chromium
Version        : 38.0.2125.111-1
Build Date     : Mon 27 Oct 2014 05:11:09 PM EDT
Install Date   : Wed 29 Oct 2014 01:48:55 PM EDT

fedora 21, after a quick test, the problem does not seem to occur anymore

Also affected:
 * Ubuntu 14.10
 * Chrome 38.0.2125.104 (64-bit)
 * GNOME Shell 3.12.2

Changed to "use system title and bar" setting and don't see any more crashes (I'm with gnome 3.14.2).

I've seen hangs while using the system titlebar with GNOME 3.12.

I've stopped seeing hangs once I upgraded to GNOME 3.14.
2014 gruod. 9 14:34 <chromium@googlecode.com> rašė:

The same happens to me and my girlfriend on our computers.

In my case, I changed my disk to a SSD and now seems to have solved, so I think it can be some race condition that creates an infinite loop.

We both are using Elementary OS.

I am having same issue, Arch Linux Fully Updated, Chromium 39.0.2171.95 (64-bit), Corsair Force 3 128GB SSD and still have issue both with Use System Title Bar and Borders on and off. Enlightenment Window Manager Xorg 1.16.3. I have window borders disabled. The entire window seems to be deselected when the issue occurs for a moment. Only occurs sometimes. I am using Custom Theme with Chromium and custom GTK window decorations. Chromium freezes for a long while and then eventually crashes (due to a timeout?). I am getting that white box just as in the top screenshot.

I can not reproduce the issue when I turn window borders back on in Enlightenment as long as Use System Title bars and Borders is on.

It just happened again, this is very annoying, take a look:

http://youtu.be/M0f4CjCuCvg

I'll try ti disable "[] Use system title and bar borders"...

I'm running Ubuntu 14.10 with Unity but I also have Enlightenment DR19 installed (preferred for me).

BTW, which is the latest working version for Linux? I need to downgrade it.

Thanks!
Thiago

I disabled the Chromium option:


 [ ] Use system title bar and border


And it is working for about 24H without a single crash!

Damn it... It just crashed again...  :-@

Chrome force closed on me half a dozen times with the same symptoms.

Hey guys!

 I disabled the Chromium option couple days ago:


 [ ] Use hardware acceleration when available


 ...and I'm running it for about two days without a single crash! Hope it remains stable from now on...

Cheers!
Thiago

Damn it! I can not even talk about this issue, then, it crashes. I'll not say a word anymore, maybe, Chromium will stay alive...  \o/

One interesting point, every time I open the "Settings" page, to see what option I disabled, to reply back here for you guys, then, it crashes right after closing it [Settings page]!

This had happened two times. Maybe it is just a coincidence.

I'll wait two more days, before reopening the "Settings" page again, to see if it crashes right before I close it.

This bug is very annoying...

Best,
Thiago

Hey guys,

The latest Chromium is near to useless on Linux (it affects Opera, and "Stable" Chrome as well).

The output of chromium-browser on Ubuntu 14.10 looks like this:

----
user@utopic-1:~$ chromium-browser 
ATTENTION: default value of option force_s3tc_enable overridden by environment.
Fontconfig error: Cannot load default config file
Fontconfig error: Cannot load default config file
[7942:7942:0102/181230:ERROR:browser_main_loop.cc(209)] Gdk: gdk_window_set_user_time called on non-toplevel
[7942:7942:0102/181230:ERROR:browser_main_loop.cc(209)] Gdk: gdk_window_set_user_time called on non-toplevel
[7942:7942:0102/181231:ERROR:browser_main_loop.cc(209)] Gdk: gdk_window_set_user_time called on non-toplevel
[7942:7942:0102/181236:ERROR:browser_main_loop.cc(209)] Gdk: gdk_window_set_user_time called on non-toplevel
[7942:7942:0102/181236:ERROR:browser_main_loop.cc(209)] Gdk: gdk_window_set_user_time called on non-toplevel
[7942:7942:0102/181238:ERROR:browser_main_loop.cc(209)] Gdk: gdk_window_set_user_time called on non-toplevel
[7942:7942:0102/181238:ERROR:browser_main_loop.cc(209)] Gdk: gdk_window_set_user_time called on non-toplevel
[7942:7942:0102/181238:ERROR:browser_main_loop.cc(209)] Gdk: gdk_window_set_user_time called on non-toplevel
[7942:7942:0102/181247:ERROR:browser_main_loop.cc(209)] Gdk: gdk_window_set_user_time called on non-toplevel
[7942:7942:0102/181248:ERROR:browser_main_loop.cc(209)] Gdk: gdk_window_set_user_time called on non-toplevel
[7942:7942:0102/181250:ERROR:browser_main_loop.cc(209)] Gdk: gdk_window_set_user_time called on non-toplevel
[7942:7942:0102/181251:ERROR:browser_main_loop.cc(209)] Gdk: gdk_window_set_user_time called on non-toplevel
.........
----

I just downgraded to "google-chrome 35" until this problem gets fixed. I'm hopping that Chrome 35 doesn't froze too...

I removed Chromium with "sudo apt-get purge chromium-browser".

Hope this problem gets fixed ASAP! It is very serious.

Happy New Year Everybody!!

Best,
Thiago

I've had this issue for a few weeks now - it happens several times a day for me.

System:
- GNOME Ubuntu 14.10, fully updated.
- GNOME Shell 3.12.2
- Chrome Version 39.0.2171.95 (64-bit)
- I've attached the HTML page for chrome://gpu
- Not sure if relevant, but I do use a two-monitor setup.

Please let me know what other kind of debugging info is needed. 

chrome-gpu.html 39.3 KB View Download

After updating to GNOME 3.14.0 and Chrome Version 39.0.2171.95 (64-bit) (Sabayon 15.02) I have not experienced the hang again.

I'm a bit astonished by the way this issue was demoted to low priority. It hangs the whole browser, quite often. What I observed here is that every next person says that it may be put on a lower priority and on a later milestone (or removed from milestone totally) because it was already done before. :) 
I would expect that the fact it was postponed once, would motivate devs to fix it faster, not slower. I only see here the attitude towards linux/gnome as a low priority environment for the team.
Btw: I moved to arch so I get easy upgrade to Gnome 3.14, it fixed the issue ( I wouldn't call it "bug solved").

just a reminder to devs: it might not happen on latest GNOME but it does still happen on latest Enlightenment! fix it for fuck sake!

I'm glad I've found this bug that I'm facing for month now !

Enlightenment DR19/EFL 1.13
Chrome 39.0.2171.99 (64-bit)
Debian 8

Guys,

I'm using Enlightenment DR19 under Ubuntu 14.10, newer Chrome / Opera / Chromium does NOT work.


While the following Chrome version (35.0.1916.153) is okay:


http://ie.archive.ubuntu.com/funtoo/distfiles/chrome/google-chrome-stable_35.0.1916.153-1_amd64.deb

http://ie.archive.ubuntu.com/funtoo/distfiles/chrome/google-chrome-stable_35.0.1916.153-1_i386.deb


Please, fix this! I'm stucked with an unsupported Chrome version!


To find another mirror, Google for "google-chrome-stable_35.0.1916.153-1_amd64.deb"

Same problem here with ubuntu 14.10 64bits. Chrome 39

Same problem here:

Ubuntu 14.04, kernel 3.16, gnome-shell 3.12.2, Chrome Version 40.0.2214.94 (64-bit)

Any known fixes / workarounds? Extremely annoying...

BTW This issue looks like a duplicate: https://code.google.com/p/chromium/issues/detail?id=415928

chi997,

The workaround is to downgrade Chrome to version 35, using one of the following files:


While the following Chrome version (35.0.1916.153) is okay:


http://ie.archive.ubuntu.com/funtoo/distfiles/chrome/google-chrome-stable_35.0.1916.153-1_amd64.deb

http://ie.archive.ubuntu.com/funtoo/distfiles/chrome/google-chrome-stable_35.0.1916.153-1_i386.deb

Thanks thiagocm. This sounds like a workaround. Unfortunately as a webdeveloper it's not the best using older browser. Thanks anyway!

Do you know if the problem is related only to gnome-shell or chrome?

Okay chi997, I understand your concerns...

I believe that it is not related to gnome-shell, I'm using Enlightenment DR19 and it freezes here as well, also when with Unity.

It is a Chrome fault, for sure... Or some incompatibility with recent Linux DEs... Nevertheless, I'm seeing comments that when with new gnome 3.14, the problem does not appear.

I'm about to upgrade to Ubuntu 15.04 Alpha2 to test it, since it comes with GNome 3.14.

I'll post the results here during next week...

These freezes went away from me when I upgraded my Ubuntu GNOME 14.10 to GNOME 3.14 using this PPA: https://launchpad.net/~gnome3-team/+archive/ubuntu/gnome3-staging

(Read the warning before attempting to use it.)

I'm running Enlightenment DR19 on Debian 7.8 with a dual monitor setup and Chrome freezes for me, too.

Does anyone have NVIDIA chipsets?  I do, and I'm running the latest proprietary driver.  I thought I read that somebody disabled hardware acceleration and it fixed the freezing, but I can't find it again.

Chrome 40.0.2214.95 (64-bit), Ubuntu 14.04, kernel 3.16, gnome-shell 3.12.2 - issue has gone.

Sorry guys, after reboot issue still exists.

Well I am using AMD Hardware with Open Source Drivers and I tried
disabling at least a few hardware acceleration options (was ages ago)
and it didn't help.

I have this bug on many ubuntu/gnome shell for some month   

01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Cape Verde XT [Radeon HD 7770/8760 / R7 250X]

I have testing many drivers , but still the bug.
Please make a effort on this bug, it's very boring.

How to deactivated the alt and title attribute on <img>?  (some workaround here?)

I'm using now, Chrome 40.0.2214.111-1 on Ubuntu 15.04 with Unity.

I am not seeing this problem anymore.

BUT, when with Ubuntu 14.10 or 14.04, the latest Chrome 40 still have this
problem.

In about 10 days, I'll move back to Enlightenment and/or GNome, to see if
this problem appear again.

Same problem. It is quiet annoying.

40.0.2214.115 (64-bit)
Lenovo T440
Ubuntu 14.04 + Gnome 3.12.2
Linux 3.16.0-30-generic

I too have the same issue
40.0.2214.115 (64-bit)
Lenovo x201
Ubuntu 14.05 + gnome 3.12.2
Linux 3.13.0-24-generic

Sux.  Same problem.  E19 from git master and 42.0.2305.3 dev 64-bit.  Ubuntu 14.04.2.

I have had this issue for ages and it crashes my browser at least twice a day.

Really sad to see the posted solution is to "downgrade to Chrome 35"

Another possible solution is to upgrade to Ubuntu 15.04... I'm using
it now, the GNOME version (not Unity)... Most recent Chrome did not
crashed anymore on top of Ubuntu 15.04.

I'll try it with Enlightenment again next week.

I was very unhappy after updating from Enlightenment 17 to Bodhi 3 with E19 to see this peculiar bug and did one thing: changed the "Application priority" in E19 settings from 3 to 1 and the bug disappeared. Later on i changed this setting back from 1 to 3 and it's been 1 day i haven't seen the bug appear again. I'm using an old NVIDIA graphic card.

"Application priority" ??? Where is that???????????????/

I'm really tired of the "I did random thing X, or updated Y, it went
away." posts. Invariably the person returns and says it came back.
Since it's a random bug, unless you are being absolutely vigorous with
your testing, please don't claim it "went away".

I can assure that this BUG does not appear when using latest Chrome on
top of Ubuntu GNOME 15.04.

But it appears when using, the very same latest Chrome, on top of
Ubuntu 14.10 or 14.04 with "Unity / GNOME / Enlightenment-19".

I will happily upgrade to 15.04 if it somehow resolves this bug, thiagocm I will try upgrading releases and let you (all here) know if it helps.

For comparison, I have a chrome or chromium on Debian Sid on another machine with E17 that never has this issue.  I've been in the office now for less than an hour on my 14.04 / E19 trunk, and I've already very nearly suffered this crash once.

When I see the empty tooltip, sometimes the browser hasn't crashed yet, and I can get away with keeping all of my tabs in every background window open if I close the current window.

I will prosibly need to recompile E19 once I upgrade all my system's shared libs.  Here we go.  Attached dpkg -l from before taking the plunge: http://pastebin.com/jnetVVeE

Halfway done upgrading for science: http://pastebin.com/F7R4eNFk

Ghetto-bisect, if the depended software has been fixed somehow in 15.04, it might have been fixed in 14.10.  If I am still getting the crash in two days or less, I'll definitely try the next release upgrade and post what versions are in dpkg.

If not, we can start to conjecture about which package has fixed the issue between 14.04 and 14.10 release current versions.

For completeness of documentation, I put all of my PPAs back in and upgraded any to utopic that had distro release repo tags in their sources.list.d entry.

This resulted in a newer build of google-chrome-unstable installing for utopic too: 42.0.2311.11-1

dpkg -l again For science: http://pastebin.com/JCzUc9sV

20 hours since release-upgrade to 14.10, 20 hours since my last blank/empty tooltip.  Not ready to call it yet, but not ruling out that it is fixed.  Still don't know why or related to what dpkg dependencies.  https://www.google.com/?q=google%20chrome%20tooltips%20freeze

If we can find out and it's not "the whole Gnome 3.14 dependency stack" -- eg, this problem is probably solved in one library and it's not necessary to upgrade your whole Ubuntu Release or fetch updated blibs from a PPA off some guy's LAN.  If that lib can be upgraded standalone, maybe we should propose it for trusty-backports?  That's a thing with LTS releases, right...

I'm sure you want to support LTS releases on at least one channel of Chrome, right

For what it's worth, I've been on 14.10 since it came out in October and still have this tooltip issue every few days, though I'm running Enlightenment 19. So if it's some dependency that's preventing this from happening, it's likely something in Gnome itself that changed.

-Dan

OK, seconded, we just ruled out 14.10 as being "new enough stack to fix this bug", I just triggered the crash again.

It's interesting now after reading this bug report, I feel much equipped to trigger the bug at will, or avoid it.

So, I'll post dpkg listing again when I've finished upgrading to dev 15.04, and probably recompile E19 again on the new library stack.

--Kingdon

Upgrade done.  Will report back in a few days.

To refute or confirm: 14.04, 14.10 both suffer from this bug, but 15.04 no longer does as reported by thiagocm...

14.10 (dpkg -l) http://pastebin.com/G4tNUxTP
15.04 (dpkg -l) http://pastebin.com/XuzQHrbp

If true, whatever was fixed is somewhere in that listing.  Empty lines have been added to make side-by-side diffs easier, so entries that have appearances on either side of the upgrade should appear on the same line number.

If it turns out it still crashes on 15.04, then I guess nobody will care.

I am skeptical that for thiagocm it somehow is fixed by running Gnome (and not just by upgrading some/one of the shared dependencies), but as I am running Enlightenment 0.19.99.19590 from git master, I suppose I can't rule it out unless I tried.  I guess there may be something in the compositing code.  We'll see if it still crashes, but this is heisenbug and might take several days to confirm.

No crashes so far on Ubuntu 15.04+E19.

I just spent half an hour trying to trigger this bug and could not.  So far 24 hours of my tooltips rendered 100% ok and didn't blink out or crash anything.

I just triggered a blank tooltip somehow, but was not able to get it to crash the browser.  The tooltip stayed blank on the screen for a while.  Other tooltips came and went, no crash.  I was cleaning up windows about to get a screenshot of what was happening, but I made a mistake and closed the wrong window (I thought the tooltip came from the incognito window I had in the foreground?) and it disappeared.

Normally any of that would have crashed the whole browser as soon as the second tooltip was being displayed.

This has never happened before.  So now, two days no crash.  I am close to accepting now that this was fixed by a dependency upgrade some place inside of Ubuntu 15.04.

It took 5 days, but I just got another blank tooltip that crashed the whole browser in short order.  The bug is not fixed in Ubuntu 15.04 current dev edition.  The behavior appears to have changed slightly, but the basic description of the bug is the same.

After some time, a blank tooltip appears.  The next tooltip (or the next after that) will invariably crash/hang the browser, leaving no option but to kill with SIGKILL.

The behavior seems less common with totally up-to-date dependencies, but it is still there, tendency seems to be to manifest more readily when the whole system is under heavy load (from a lot of Chrome tabs.)

Getting this exact crash maybe 4-5 times a day, but it is becoming more frequent.

Using Chrome 41.0.2272.89 (64-bit) on Ubuntu 14.10 and GNOME Shell 3.12.2.

Running on a Sony VAIO VPCZ13M9E using discrete graphics.

Hope some of this info can help fix this productivity killing bug. Severity is such that I have had to switch to Firefox for some essentials such as online banking.

On gnome shell 3.14 there are no freezing tooltips. But I have another hang issue: after locking-unlocking system chrome completely freezes. It seems that gnome doesn't like chrome (or vise versa) :(

Chrome 40.0.2214.93, Ubuntu 14.10.2 Gnome shell 3.12.2-1ubuntu7, still it is crashing.

Chrome 41.0.2272.89 (64-bit), Ubuntu 14.10, Gnome shell 3.14.3, no more tooltip crash.

Chromium 41.0.2272.76 (64-bit), Debian 8.0, Enlightenment 19. Tooltip crash still happens.

freeone3, you are the first report I have seen of Debian chrome user who has this issue.  At home I use Debian Unstable (I think?) + Google Chrome or Chromium and it does not crash like this.  Maybe it has been fixed somewhere since Debian 8.

On Ubuntu 15.04 with the latest everything, I still get the empty tooltip, approximately just less frequent than once per day, but I have grown accustomed to it and am usually able to notice and close all tabs in the current window to dismiss the tooltip before another one tries to open and fails, crashing the whole browser.

It is decidedly less than optimal.

Can anyone suggest a course to debug this?  It would certainly help if we had reliable steps to reproduce the issue.  I don't think it's going to work for anyone to run Chrome under gdb for a few days until the bug can be triggered.

Hey guys!

My "Ubuntu 15.04" with "Chrome 41.0.2272.101-1" have right now, 7 days of
uptime.

My machine have 4G of RAM memory, and 12G of Swap on SSD (12G used in
total). I have about 30~40 tabs opened at chrome, system under HEAVY load,
all day long.

No signal of this problem.

I have a Macbook Air.

Cheers!
Thiago

Hangs on Ubuntu 14.04 
Chrome Version 41.0.2272.101 (64-bit)

Happening on Elementary OS Freya.
Just upgraded from Luna(12.04)few days ago had no issues on that version.

Kernel: 3.16.0-34-generic #47~14.04.1-Ubuntu
Chrome: Version 42.0.2311.90 (64-bit)

Switching to FF if this carries on.

I've had it consistently on Ubuntu 14.04, GNOME.
Whenever this happens though I simply open the gnome-system-monitor and stops the process "chrome -type=gpu-process" then all my windows become active again. Try it out, it might work for you.

Hmm.  So this is probably an accelerated graphics issue!

Now that you mention, I would note that my NVidia ION3 board (I mentioned before, running Debian Sid) does not experience this issue,

but my ASUS quad-core S56CA/K56CA running Ubuntu 15.04 with a "VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller" and Intel(R) Core(TM) i5-3317U CPU suffers this issue every day again, like when I first posted from 14.04.

Using pretty standard Open source Mesa drivers, whatever X is loading sans xorg.conf, the onboard video hardware from Intel.

OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Ivybridge Mobile

Thanks for the helpful report m.gr...!

Ubuntu 14.04.2 LTS 64-bit,  Chrome Version 42.0.2311.90 (64-bit), Tooltip crash still happens 2 or 3 times for a day.

Please include hardware and driver information with reports.

Using google-chrome-unstable  43.0.2342.2-1  amd64 on Ubuntu Vivid.. 15.04,

I did not see any type=gpu-process until I killed the type=gpu-broker.  Killing either one seems to just spawn another, in alternating fashion, but does not restore the process to working state.  This is following the suggestion of #c113 from m.gr...@gmail.com above, killing any chrome type=gpu-process to bring Chrome back from the dead, it did not work for me.  Chrome stayed zombified/dead until I killed off /all of the/ chrome processes, then it normally restored tabs as usual when I brought it back by starting again.

It is possible we reported different bugs, or possibly more likely there has been some treatment of Chrome subsystems related to this bug since Ubuntu 14.04 (but no fix) so we are observing the symptoms differently.

Possibly related: The current development build of kdenlive creates these empty tooltips as well that just sit there and never disappear. Though it doesn't crash/hang anything. 

Using kdenlive Version 15.04.0; KDE Frameworks 5.3.0
Chrome Version 44.0.2369.0 dev (64-bit), Ubuntu 14.10, Gnome.

	Bildschirmfoto von »2015-04-20 17:29:30«.png 5.1 KB View Download

#c118, your screenshot is not clear.  Also, please include hardware and driver information with reports.  I believe this is an issue related to specific hardware drivers, and from your report I now suspect it might not even be a Chrome issue at all.  But I'm not able to tell from your screenshot if it's even remotely similar.

What you see in that screenshot is the top left corner of the German interface of kdenlive that just loaded up. 

The tooltip, unlike the one chrome generates, isn't white but contains whatever is behind kdenlive when starting it, which is in this case Chrome. 

A similar thing also sometimes happens in the Steam client (which is a heavily modified version of Chrome 35).


You're right that this isn't a Chrome bug (respectively kdenlive and Steam), but since it this issue appears for all three of them, I think it's likely that the bug lies in a shared library. 
 
Using a nvidia gtx 660m with driver version 331.113. 

I also agree that this isn't a Chrome BUG, since I'm not seeing it anymore
with Ubuntu 15.04.

But the very same Chrome binaries, on Ubuntu 14.10 / 14.04, triggers this
problem.

My hardware is a Macbook Air.

Can't stand this anymore... crashing twince an hour right now. 

e19 0.19.99.19282
chromium 39.0.2171.71

	chrome_bug.png 2.3 KB View Download

I don't believe this occurs in Ubuntu 15.04 so I'd recommend you upgrade to
that, or just switch to Firefox (which is what I did). Their memory
management and sync and android version are a lot better than years ago.
Its worth it.

Please stop repeating this everyone, it's not fixed in Ubuntu 15.04

I don't know why for you and thiagocm it appears to be fixed, but I can assure you I've been on 15.04 for the duration of my reporting since #c101 up above, and I still suffer from this bug.

If you fixed it somehow, it wasn't by upgrading to 15.04 (or for some hardware reason, your experience is different than mine, I'm not trying to call you a liar!)

This bug still affects me daily.  I just had one only minutes ago.  Some time I will try and wipe my whole system clean and install 15.04 or 15.10 freshly, but I do have a doubt that doing it will somehow resolve to different results for me.

Fortunately I do not get this result on ARM Chromebook too or I'd be throwing the thing in the trash, and converting myself back to Firefox already like it's 2009

I think it's the Gnome upgrade that fixed it. I'm on Ubuntu 14.10 and Gnome 3.14.3 now. I had the problem every day while on an earlier Gnome version, but not since the Gnome upgrade. Maybe some people somehow upgraded Gnome with Ubuntu and you didn't?

I confirm comment #125, I also earlier using Gnome 3.12 (in ubuntu 14.04...) and now I have changed to Fedora21 with Gnome 3.14 - problems gone.

Since change I see sometimes tooltip in tabs with half of it scratched.

Still happening on Ubuntu 15.04, Unity and Chrome 42. Not only Chrome becomes unresponsive, but it makes it impossible to interact with Unity either.

Killing the chrome gpu process helps in my case.

Can you run gnome-shell --version and put the result here?

Just for the record:

---
martinx@vivid-1:~$ dpkg -l | grep google-chrome
ii  google-chrome-stable                                 42.0.2311.90-1
                        amd64        The web browser from Google
---

Ubuntu Vivid - 64-bit, running on a Macbook Air:

---
martinx@vivid-1:~$ lsb_release -ra
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 15.04
Release: 15.04
Codename: vivid


martinx@vivid-1:~$ lspci
00:00.0 Host bridge: Intel Corporation 2nd Generation Core Processor Family
DRAM Controller (rev 09)
00:01.0 PCI bridge: Intel Corporation Xeon E3-1200/2nd Generation Core
Processor Family PCI Express Root Port (rev 09)
00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core
Processor Family Integrated Graphics Controller (rev 09)
00:16.0 Communication controller: Intel Corporation 6 Series/C200 Series
Chipset Family MEI Controller #1 (rev 04)
00:1a.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset
Family USB Universal Host Controller #5 (rev 05)
00:1a.7 USB controller: Intel Corporation 6 Series/C200 Series Chipset
Family USB Enhanced Host Controller #2 (rev 05)
00:1b.0 Audio device: Intel Corporation 6 Series/C200 Series Chipset Family
High Definition Audio Controller (rev 05)
00:1c.0 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family
PCI Express Root Port 1 (rev b5)
00:1c.1 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family
PCI Express Root Port 2 (rev b5)
00:1d.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset
Family USB Universal Host Controller #1 (rev 05)
00:1d.7 USB controller: Intel Corporation 6 Series/C200 Series Chipset
Family USB Enhanced Host Controller #1 (rev 05)
00:1f.0 ISA bridge: Intel Corporation QS67 Express Chipset Family LPC
Controller (rev 05)
00:1f.2 SATA controller: Intel Corporation 6 Series/C200 Series Chipset
Family 6 port SATA AHCI Controller (rev 05)
00:1f.3 SMBus: Intel Corporation 6 Series/C200 Series Chipset Family SMBus
Controller (rev 05)
02:00.0 Network controller: Broadcom Corporation BCM43224 802.11a/b/g/n
(rev 01)
03:00.0 PCI bridge: Intel Corporation Device 151a (rev 01)
04:00.0 PCI bridge: Intel Corporation Device 151a (rev 01)
04:03.0 PCI bridge: Intel Corporation Device 151a (rev 01)
04:04.0 PCI bridge: Intel Corporation Device 151a (rev 01)
05:00.0 System peripheral: Intel Corporation Device 151a (rev 01)
---

No sign of this problem.

I also have it (Vivid 64-bit + Chrome) running at my Desktop:

- MOBO Gigabyte 990FXA UD7
- CPU: AMD FX-8150
- Video: Radeon PCI-e 5450

Also not affected.

I don't have gnome-shell installed and I get this problem regularly on Ubuntu 15.04.

Haven't getting any crash since upgrading from Ubuntu GNOME 14.10 to 15.04
three weeks ago.

gnome-shell 3.14.4-0ubuntu1
google-chrome-stable 43.0.2357.81-1
(both on amd64)

As I mentioned in #38, the problem vanished after some time. But now it's back since a few days, and happens very regularly. My current environment is:

* Chrome Stable 43.0.2357.81 (Official Build) (64-bit)
* Fedora 22, Gnome-Shell 3.16
* Intel Haswell graphics
* 3 displays

A reliable way to trigger the bug is:
1. Open two windows on the same display
2. Move one of the windows to another display
3. Change focus back to the window on display 1

I attached a screencast of this happening. Notice how the cursor stops blinking in the location bar when the UI freezes.

aura_freeze_381732.ogv 6.9 MB Download

To add to #133:

While I at times *have* seen an empty tooltip just like in the original report, the bug as described in #133 at least isn't *triggered* by tooltips. Shall I open a new issue?

Happens in Opera on Enlightenment as well. Likely an issue when running this browser engine in a composited desktop environment.

Ubuntu 14.04, gnome 12.2, Very annoying

After I updating to Chrome 44.0.2403.89, I can no longer use it.
It hangs the system instantly.

I think this is a "nouveau lockup"

Same problem, occasionally freezes especially on scrolling heavy loaded pages. Setup:

 * all chromiums up to the current version are affected on my machine (Version 43.0.2357.130 Ubuntu 14.10 (64-bit))
 * Video: Intel i915 (both default and intel 01.org drivers tested)
 * Desktop: GNOME Shell 3.12.2
 * Platform: Ubuntu 14.10, Linux 3.16.0-44 (the same with a number of previous kernels)

Similar symptoms Kubuntu 15.04  - UI freeze 

In the picture it seems youtube is shown, but actually it is amazon.

Video: Intel Iris 6100
Chrome: Version 44.0.2403.125 (64-bit)

Linux 3.19.0-25-generic #26-Ubuntu SMP Fri Jul 24 21:17:31 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

	snapshot2.png 1.2 MB View Download

Linux 4.1.4-1-ARCH
Version 44.0.2403.130 (64-bit)
DE: E19
Video: Nvidia 340.76, GeForce 310M

It looks like my XFCE4 isn't affected by this issue, 
Can anyone else confirm this?

Cheers

Linux 4.1.4-1-ARCH
Version 44.0.2403.125 (64-bit)
DE: E19.5
Video: GeForce GT 220, Nvidia 340.76-13

Never had this problem. Just applied outstanding updates.  Now this happens in Chrome continuously.  Even pressing the power button can't get ACPI to popup the shutdown button - gui totally locked.
This issue has been open a year, I guess there won't be a fix.  So long Chrome.

3.13.0-61-generic #100-Ubuntu SMP Wed Jul 29 11:21:34 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

hardinfo_report.html 59.0 KB View Download

Have been suffering the same on Ubuntu 15.04 and earlier 14.10, w/ Gnome wm, Version 44.0.2403.157 (64-bit). Frustrating at best.

Kubuntu 15.04 / 4.1.8-040108-generic

Starting chrome from the terminal with either Nvidia 355 or Intel i915 graphics produces the following line in the terminal:

Fontconfig error: Cannot load default config file

Unable to replicate the reported crash, tooltips are ok.

Enlightenmrnt 0.19.99.20573
Debian 8 Jessie (SparkyLinux)
Radeon HD 6410D
Google-Crome-Stable 45.0.2454.101 (64-bit)
-
freezes. for a long time and regularly. illustration:

	Gsumm_.png 343 KB View Download

For those experiencing the hang, can you try the steps here and either generate a crash report id or crash dump? https://www.chromium.org/for-testers/bug-reporting-guidelines/hanging-tabs -- replace "hung tab" in the instructions with "browser".

Just happened to me.  Attached are some logs (on Fedora so the only logs I found were in systemd journal since .xsession-errors didn't exist).

xdump.txt 83.7 KB View Download

re: comment 150 - please see comment 148. The logs you attached does not look immediately useful.

The memory dump isn't being generated (No DWARF information found, see the attached log).  Killed the browser process using kill -SEGV <browser process id> found from chrome taskmanager.  

sorry. log here.

xdump2.txt 39.3 KB View Download

re: comment 152 - The Fedora ABRT tool is probably intercepting the crash. Please try turning that off and let Google Chrome intercept its own crash via Breakpad and generate/upload a crash report.

Turned off ABRT and a crash just occurred.  My uploads.log in the chrome crash reports directory has a file modified time corresponding to the crash and this information is in it:

1444402176,105182ed3a122e4e
1445524259,79f309ddb8520074

Is this what you need?

re: comment 155: Thanks for providing useful data! I looked at 105182ed3a122e4e, which was with Chrome 45.0.2454.101:

#0  0x00007f2a7d8622fd in poll() at ../sysdeps/unix/syscall-template.S:81
#1  0x00007f2a7bd9d182 in poll() at /usr/include/bits/poll2.h:46
#2  _xcb_conn_wait() at xcb_conn.c:459
#3  0x00007f2a7bd9ea17 in wait_for_reply() at xcb_in.c:516
#4  0x00007f2a7bd9eb21 in xcb_wait_for_reply() at xcb_in.c:546
#5  0x00007f2a823681f7 in _XReply() at xcb_io.c:602
#6  0x00007f2a80353285 in XScreenSaverQueryInfo() at XScrnSaver.c:220
#7  0x000055c8b5c49c2a in ui::IdleQueryX11::IdleTime() at ../../ui/base/idle/idle_query_x11.cc:38
#8  0x000055c8b5c49b1f in ui::CalculateIdleTime()() at ../../ui/base/idle/idle_linux.cc:19
#9  0x000055c8b81124c9 in extensions::(anonymous namespace)::DefaultIdleProvider::CalculateIdleTime() at ../../extensions/browser/api/idle/idle_manager.cc:90
#10 0x000055c8b811234e in extensions::IdleManager::UpdateIdleState() at ../../extensions/browser/api/idle/idle_manager.cc:234
#11 0x000055c8b568cc5c in Run() at ../../base/callback.h:396
#12 base::Timer::RunScheduledTask() at ../../base/timer/timer.cc:213
#13 0x000055c8b56a42d8 in Run() at ../../base/callback.h:396
#14 base::debug::TaskAnnotator::RunTask() at ../../base/debug/task_annotator.cc:62
#15 0x000055c8b565ea41 in base::MessageLoop::RunTask()

So why is it crashing in XScreenSaverQueryInfo()? No idea. +zork@ who orignally wrote the ui::IdleQueryX11::IdleTime() code.

A quick search turned up https://bugs.kde.org/show_bug.cgi?id=303582 which is similar. That bug got marked fixed without a clear explanation of how. My reading of the KDE code is that they simply stopped using XScreenSaverQueryInfo().

The other mystery is why this hangs for some distro + windows manager (+ hardware possibly???) combinations, but not for others. At least now we now know where this is happening. Perhaps one should try reporting this to the Linux distro / window manager and see what they say about it. All Chromium/Chrome is doing is asking X for its screen saver status.

and s/orignally/originally/ in the previous message.

Right... Ubuntu Desktop 14.04 (Unity) on a Macbook Air, it happens ~10
times a day... I tried Enlightenment, GNome... Same problem...

Unfortunately, I moved to Mac OSX because of this problem... And now,
my Ubuntu is a VirtualBox VM, which sucks but, at least, I have my
Linux tools and a stable Google Chrome on OSX.

2 things: 

1) The machine with the reported error in #155 has Nvidia  GF119 [NVS 310] graphics card running nouveau graphics driver (xorg-x11-drv-nouveau.x86_64 v1.0.11 release 2.fc22 (fedora 22)) using gnome shell version 3.16.2.

2) The crash reported was somewhat atypical in that I switched virtual desktops and the UI froze.  The typical crash involves hovering over a UI element in chrome and seeing graphics corruption in the popup tooltip.  I am sure this type of crash will occur in the near future so I'll report.  For any of these UI freezes, killing the chrome process (had to ssh in from another machine) brought the UI back from the grave.

Also, I am running the same software setup (fedora 22, gnome, chrome) on two other intel graphics based machines with no ui freezes.  It is rock solid.

re: comment159:
Do not give up!
I wish you success!

I have this issue too on Ubuntu 14.04 (and Intel 4000 HD) with Enlightenment.

But I haven't the issue with cinnamon and unity.
I haven't try with gnome.

Have been crash-free for a long time.  Just had another gnome freeze up and it was reported:  
1447873556,401f255b0b08ac80

If you can confirm that the cause is the same XScreenSaverQueryInfo() call, I can file as a fedora bug report.  

Still seeing the BlockUntilWindowMapped hang on 47.0.2526.73, GNOME 3.18.x on Fedora 23. Every time this happens, the tooltip has _already_ been mapped: it shows up with no content.

I'm going to go out on a limb and claim that this is a race, in that another thread handles the MapNotify in between calling XMapWindow/XMapWindowRaised, and BlockUntilWindowMapped. A lame but straightforward fix would be to wrap the MapWindow/BlockUntilWindowMapped calls in XLockDisplay and XUnlockDisplay.

erg@ and thestig@ could probably comment if this fixes the trybot failures seen in the initial switch to Metacity at #167114, but I can't CC them myself.

Issue 538311 has been merged into this issue.

Bug still active with : 


Enlightenment 0.20/EFL 1.16
Chrome 44.0.2403.107 (64-bit)
Debian 8

Same thing happens to me with:

Enlightenment 0.20.1
Chrome version 47.0.2526.106 (64-bit)
Archlinux with Intel drivers 2.99.917+519+g8229390

Sorry I can't provide any useful data.

Any progress? I was struggling with same issue for a year now, and yes, it's still an issue (Version 47.0.2526.111 (64-bit)).

Why is the bug still "Untriaged"?

Still an issue.  I've had to restart Chrome several times today.

System: Ubuntu 14.04.3
Arch: AMD64
Window Mgr: Enlightenment 1.20
Chrome: Version 48.0.2564.109 (64-bit)

I'm ready to go back to FireFox.

I'm not seeing ANY issues with Ubuntu 15.10, neither with 16.04.

I'm already on 16.04 since day Alpha1...   ;-)

For those claiming "no issue" -- this bug depends on your window manager.

I don't think that it depends on the Window Manager.

When the BUG is present, it happens no matter which Window Manager your're
suing.

When the BUG is not present, it works with all Window Managers!

I am using enlightenment and chromium was freezing multiple times per day on eg inbox.google.com. Today I got rid of gnome/gnome-shell/gtk etc and the freezes stopped! The looks of the window are different, so it seems that if gtk is not present, the locking up code doesn't execute (or at least the deadlock doesn't occur).

Using Fedora 23- Gnome, GTK, etc.  No change in workflow, and have not encountered any further problems since approximately Dec 15. Prior to that, was crashing almost daily (See #123 and other previous reports).

Update: after getting rid of gnome/gnome-shell/gtk, I've only seen one freeze during 3 days of usage. So it helps a lot, but not completely.

I've got same freez with chrome at home (Ubuntu 14.04, Gnome-Shell 3.12, NvidiaGPU with official drivers 340.96). And at work (Ubuntu 14.04, Gnome-Shell 3.10, NvidiaGPU with official drivers 35*.**) I have the same problem but with PhpStorm, application written in java. 

I've got the same freeze with a:
Google Chrome Version 49.0.2623.75 (64-bit)
on:
LSB Version:	core-2.0-amd64:core-2.0-noarch:core-3.0-amd64:core-3.0-noarch:core-3.1-amd64:core-3.1-noarch:core-3.2-amd64:core-3.2-noarch:core-4.0-amd64:core-4.0-noarch:core-4.1-amd64:core-4.1-noarch:security-4.0-amd64:security-4.0-noarch:security-4.1-amd64:security-4.1-noarch
Distributor ID:	Ubuntu
Description:	Ubuntu 14.04.4 LTS
Release:	14.04
Codename:	trusty

Maybe this publication will help ?: https://phab.enlightenment.org/T1759
I do not want to abandon the Enlightenment

It's strange as it seems very linked to web sites. Some webapps can reproduce the crash with a 100% accurary while it may seem more arbitrary on others.

flickr.com is one the worst to me. I have to elaborate a mouse borwsing strategy, to avoid pictures and avoid tooltips... a pity.

I'm seeing this with chromium-49.0.2623.75 and chrome-48.0.2564.82 on gentoo linux kernel 4.4.4

NVIDIA GPU 
gnome 3.18

It's got more frequent after upgrade. Not it's hanging every few hours.
Version 49.0.2623.87

Here's another hang dump right after "tooltip" artefact appears:
report_id:bed8c96400000000

In case nobody mentioned it:
it doesn't hang immediately, first it show this strange little rectangle which appears to be an independent hanging window. This rectangle is there even if chrome is hidden, an on every workspace. Chrome hangs right after the next tooltip is starting to appear.

I got the same tooltip freezes. a lot.

Base System: Ubuntu 14.04.4 LTS 64-bit
Browser: Chromium 49.0.2623.87 Ubuntu 14.04
Video-driver: Kernel driver in use i915 (Intel)
Gnome: GNOME Shell 3.12.2
Xorg: xorg-server 2:1.17.1-0ubuntu3.1~trusty1

dump1.txt -- with kill -SEGV <browser process id> found from chrome taskmanager when chromium-browser started from terminal. instructions used from https://www.chromium.org/for-testers/bug-reporting-guidelines/hanging-tabs (There isin`t "Automatically send usage statistics and crash reports to Google" option at all)
gdb-chromium.txt -- with instructions from https://wiki.ubuntu.com/Chromium/Debugging
gdb-chromium-single.txt -- with instructions from https://wiki.ubuntu.com/Chromium/Debugging (Debugging child processes)
strace.txt -- started with strace and loggend until killed.

also when i start chromium-broser from terminal i get errors:

[22095:22095:0325/141922:ERROR:browser_main_loop.cc(245)] GTK theme error: Unable to locate theme engine in module_path: "murrine",
[22095:22095:0325/141922:ERROR:background_mode_manager_aura.cc(13)] Not implemented reached in virtual void BackgroundModeManager::EnableLaunchOnStartup(bool)
[22095:22095:0325/141923:ERROR:logging.h(813)] Failed to call method: org.freedesktop.DBus.ObjectManager.GetManagedObjects: object_path= /: org.freedesktop.DBus.Error.UnknownMethod: Method "GetManagedObjects" with signature "" on interface "org.freedesktop.DBus.ObjectManager" doesn't exist
[22095:22095:0325/141923:ERROR:logging.h(813)] Failed to call method: org.freedesktop.DBus.ObjectManager.GetManagedObjects: object_path= /: org.freedesktop.DBus.Error.UnknownMethod: Method "GetManagedObjects" with signature "" on interface "org.freedesktop.DBus.ObjectManager" doesn't exist

if i can help, please provide more information about how to generate dump.

gdb-chromium-single-process.txt 9.6 KB View Download

gdb-chromium.txt 7.4 KB View Download

dump1.txt 1.2 KB View Download

strace.txt.tar.gz 310 KB Download

this code seems to be largely from https://chromiumcodereview.appspot.com/10828133 so bouncing to erg@

erg@, please see c164.

(I haven't worked on the linux port for over two years; ccing some people who might be interested and marking as Available.)

@164: I'm not sure what the race would be with; all communication for UI with X11 happens on the UI thread in the browser process. (There is some communication with X11 from the GPU process, but this is only on special windows created for the purpose of rendering OpenGL.)

(I'm not entirely confident that I've engaged with your core suggestion.)

@183: The top of that stack is:

0x00007f481734412d	(libc-2.19.so + 0x000ed12d )	
0x00007f481c588fe3	(libglib-2.0.so.0.4002.0 + 0x00048fe3 )	
0x00007f481c5890eb	(libglib-2.0.so.0.4002.0 + 0x000490eb )	
0x00007f4822223a75	(chrome -message_pump_glib.cc:309 )	base::MessagePumpGlib::Run

Or: it's just waiting in glib.

@185: those dumps don't appear to contain a stack.

I'm not sure which process I should send SIGSEGV to and when.

When the blank/corrupted tooltip occurs (but browser still responsive) or when browser totally freezes?

When I close the tab which caused the blank tooltip to appear, browser remains responsive.

How can we debug the problem when tooltips hang but the browser remains responsive? If we send SIGSEGV, the stacktrace wouldn't show when the last tooltip is shown, would it?

Looks related to https://bugs.chromium.org/p/chromium/issues/detail?id=442111

In case this helps:

dpkg -s libglib2.0-0
Version: 2.40.2-0ubuntu1

Guys, how can I remove myself from this bug list?

I don't want to receive messages from this bug anymore, since it is fixed on Ubuntu versions 15.04, 15.10 and 16.04.

Thanks!

#195 - click on the star at the top box -
"★  Issue 381732
Starred by 81 users"

@189: Thanks for the response. Funnily enough, it just happened again - crash dump 3edfa28c00000000 from a forced SEGV after manually verifying the UI process was stuck in XWindowEvent with StructureNotifyMask, i.e. proxy for MapNotify. Again, the tooltip had already been mapped.

I'm not really sure of Chromium's internals, but the only way I can think of for a message to go missing like that would indeed be if some other thread were dispatching events in the meantime. Certainly _something_ is happening to make it go awry, of which the two basic possibilities are the event having been dispatched in the background with no-one noticing, or the window already being mapped when XMapWindow is called, and thus no MapNotify generated. The latter possibility would be easy to catch, by adding a screaming assert(XGetWindowAttributes(dpy, xwindow_, &win_attr) == Success && win_attr.map_state == IsUnmapped) on whichever codepath is calling into XMapWindow/BlockUntilWindowMapped, from my crashdump linked above.

Are you able to suggest someone who does work on the Linux port who would be able to help look into this? I'm more than happy to do what I can (within the limits of not being able to rebuild actual-Chrome ...), since this bites me incredibly often, in both Chrome and Atom, and seems to be hitting quite a few others too.

Does Chrome use Gnome libraries? Or does it use X Window directly?

Is there a flag to disable tooltips completely as a workaround?

Workaround is to upgrade to Ubuntu 16.04...

@200: No, it's not. Changing the environment can increase or decrease the possibility of tripping over this bug, but it does not fix it. Even though you aren't seeing it right now, it is not fixed.

Upgrading to Ubuntu 16.04 will not fix this.

I'm on Arch, updated today, still seeing this in several applications, with the only likely common thing being that they're all based on GTK.
"Gnome Shell" should be removed from the title as this happens regardless of the desktop environment used.

As mentioned earlier; PhpStorm has the same issue, but for me it doesn't crash and the stuck tooltip can be removed by triggering a new one in the same widget (like the file navigator), move the cursor and let the tooltip disappear completely before moving the cursor completely out of the widget.
Exactly the same in Steam.

That workaround is not possible in Crome/Chromium as attemting to trigger a new tooltip usually leads to a crash instead.

I second that by h.daniel; The bug is triggered by several window managers, e.g. enlightenment. (ref: https://phab.enlightenment.org/T2735 ) "Gnome Shell" can be replaced by "several window managers."

Indeed the first "stuck" tooltip doesn't crash or freeze chromium, but recurring stuck tooltip does.

Typically it's 2nd stuck tooltip, but some times I manage to see 3 or 4 before chromium freezes.

It is easier to trigger the bug when system is loaded. Perhaps it's a timing issue? Or an external timing issue (e.g. events from X server arriving later or in different order).

I am using it on Ubuntu 16.04 for many months now, it is fixed.

@thiagocm
If it's been fixed, please point to the commit (or release), of a library or chromium which fixed it. If we don't know what fixed it, we don't know it's really gone.

@thiago: 'It works for me' is _not_ the same as 'it is fixed'. This is not useful input. If it works for you and you no longer have any need of this bug, please click to unstar yourself from this report, and you will no longer receive any notifications.

Yeah, I can confirm that it's not fixed. I haven't had the bug in months
either and yesterday it happened again. I am using enlightenment, so I also
agree with the "several window managers" statement.
I've never seen 3 or 4 tooltips  as dimaqq states, for me it's always been
one (blank) tooltip frozen and it usually either freezes chrome right away
(possibly because a second tooltip happens very quickly after that) or the
next time a new tooltip pops.

Just to clarify, I don't mean several tooltips displayed simultaneously, rather, there's 1 tooltip at a time, that can "jump" to another location once or twice before chromium becomes unresponsive.

It's only my assumption that this "jump" is in fact a new tool tip popping up at destination and old tooltip being removed.

There's no visible time gap during the jump when neither or both old and new are seen; the "jump" looks atomic.

Some repro suggestions I received (I can't repro atm..)

1. http://www.x.org/releases/X11R7.6/doc/libX11/specs/XKB/xkblib.html is a site where everrrrrything has a tooltip, so it's easier to reproduce there.

2. Having tooltips quickly show/hide is supposed to trigger it more easily, which you can do by moving your mouse around on the page from (1) especially on borders between sections.

3. It requires a compositing manager but seems to not happen in "lighter" ones, so it needs gnome-shell or enlightenment.

(I've tried xcompmgr, mutter, and gnome-shell and no luck)

@210 Does inducing artificial load help at all?

If you write the instructions in Russian - I'll take experience
I wrote @ 147 and https://code.google.com/p/chromium/issues/detail?id=538311&thanks=538311&ts=1443731393

@210: The compositing manager requirement would explain why I've never seen this happen myself.

The crash inside hang from #197 is:

	0x000056074d5d8133	(chrome -./out/Release/../../ui/events/platform/x11/x11_event_source.cc:91 )	ui::X11EventSource::BlockUntilWindowMapped
0x000056074d0c1a2c	(chrome -./out/Release/../../ui/views/widget/desktop_aura/desktop_window_tree_host_x11.cc:1660 )	views::DesktopWindowTreeHostX11::MapWindow
0x000056074d19ace4	(chrome -./out/Release/../../cc/trees/layer_tree_host_impl.cc:1279 )	cc::LayerTreeHostImpl::UpdateTileManagerMemoryPolicy
0x000056074d19d9fc	(chrome -./out/Release/../../cc/trees/layer_tree_host_impl.cc:2057 )	cc::LayerTreeHostImpl::SetVisible
0x000056074d1bea21	(chrome -./out/Release/../../cc/trees/single_thread_proxy.cc:118 )	cc::SingleThreadProxy::SetVisible
0x000056074fbc4b5a	(chrome -./out/Release/../../chrome/browser/ui/libgtk2ui/native_theme_gtk2.cc:101 )	libgtk2ui::NativeThemeGtk2::GetSystemColor
0x000056074c61c1cf	(chrome -./out/Release/../../third_party/tcmalloc/chromium/src/tcmalloc.cc:1434 )	cpp_alloc
0x000056074d0c1890	(chrome -./out/Release/../../ui/views/widget/desktop_aura/desktop_window_tree_host_x11.cc:404 )	views::DesktopWindowTreeHostX11::ShowWindowWithState
0x000056074d0b96fa	(chrome -./out/Release/../../ui/views/widget/desktop_aura/desktop_native_widget_aura.cc:750 )	views::DesktopNativeWidgetAura::ShowWithWindowState
0x000056074d0a3d72	(chrome -./out/Release/../../ui/views/widget/widget.cc:632 )	views::Widget::Show
0x000056074d5df7ee	(chrome -./out/Release/../../ui/wm/core/default_screen_position_client.cc:26 )	wm::DefaultScreenPositionClient::ConvertPointToScreen
0x000056074d0af405	(chrome -./out/Release/../../ui/views/corewm/tooltip_aura.cc:200 )	views::corewm::TooltipAura::Show
0x000056074d0b03b7	(chrome -./out/Release/../../ui/views/corewm/tooltip_controller.cc:333 )	views::corewm::TooltipController::UpdateIfRequired

Here's MapWindow:

https://code.google.com/p/chromium/codesearch#chromium/src/ui/views/widget/desktop_aura/desktop_window_tree_host_x11.cc&rcl=1460027828&l=1621


  XMapWindow(xdisplay_, xwindow_);

  // We now block until our window is mapped. Some X11 APIs will crash and
  // burn if passed |xwindow_| before the window is mapped, and XMapWindow is
  // asynchronous.
  if (ui::X11EventSource::GetInstance())
    ui::X11EventSource::GetInstance()->BlockUntilWindowMapped(xwindow_);


I wonder if the window is already mapped sometimes. I also wonder what APIs this is talking about O__o, I've never heard such a thing.


void X11EventSource::BlockUntilWindowMapped(XID window) {
  XEvent event;
  do {
    // Block until there's a message of |event_mask| type on |w|. Then remove
    // it from the queue and stuff it in |event|.
    XWindowEvent(display_, window, StructureNotifyMask, &event);
    ExtractCookieDataDispatchEvent(&event);
  } while (event.type != MapNotify);
}


This function makes me all sorts of uncomfortable. It's processing X events out of order, and it's removing (and processing it looks like) any StructureNofifyMask events from the queue and until it finds a MapNotify, again completely out of order. I've never had anything but pain from using these APIs.

@214: Yep, pain is right ...

There are quite a few functions which rely on the window being mapped to pass (notably, setting input focus), or to do much anything useful. Rendering to a window which isn't yet mapped will result in your rendering being silently discarded.

I agree that the block function is pretty bad, but honestly, there's really not a lot you can do to avoid that in X11. The assert I suggested in c197 should be good to make sure that we're never blocking waiting for a MapRequest which never arrives as the window is already mapped. But like I said, I'll add some debugging to my local server + libX11 to see if that ever happens.

Rooting through history, that code goes all the way back to the first X11 aura patch. (https://chromiumcodereview.appspot.com/10916349). I don't recall what problem this was supposed to fix though.

Normally I think you follow XMapWindow with an XFlush() to be sure the server will know it's mapped I guess.

I am really curious what happens if we just do that, and what functions could break at that point (any?).

And if so I wonder what happens if we just XSync(d, false) instead. That should do the same without running things out of order and racing with the server state.

Not enough to just flush or sync: MapRequests are delegated to the WM to ack, so you have to wait for MapNotify. (Yes, it has been made almost impossible to implement correctly ...)

It has something to do with drag and drop. Here is the change list that added it to the (now nonexistent) RootWindowHostLinux -
https://chromiumcodereview.appspot.com/10828133

(Oops, grab, not drag and drop)

@220: I commented out all usage of the BlockUntilWindowMapped() in a local build. I didn't extensively test things but highlighting/drag and drop of text were intermittently broken, and there were BadWindow X errors printed the console when things didn't work. (Even with XFlush().)

@221: Yes, the window has to be mapped before you can grab or assign input focus to it, and neither a flush nor a sync assure that. The map request is redirected to the window manager to act on, so there's no way around waiting for the MapNotify to arrive. If it doesn't arrive, either the event loop is broken or the window was already mapped.

There are only 12 places in chromium where we call XMapWindow(). In all of them, they work on a window XCreateWindow()ed right before the map call, or a window that's owned by the class that they're a part of.

Since this only happens in some environments, I do wonder if we're having our window mapped out from under us. If so, DesktopWindowTreeHostX11::window_mapped_ would obviously be incorrect, since we set that locally when *we* map the window, since mapping for us is also setting a bunch of hints.

@223: Nope, that won't be it. I'd suggest that the tracking is broken and a map request has already been issued (but forgotten about), or the event request is broken. I'll dump tracing in the server and get back to you - and hope that doesn't blow timings out enough to mask the bug ...

Maybe we should rethink our overall approach to mapping new X windows, because polling on the thread that handles everything X related seems bad in general.  I can notice this delay when I'm watching a YouTube video and I right click on the page or click to open a bookmark folder.  The video stops rendering for ~300ms and is visually unappealing.

Perhaps both of these issues could be solved if we do one of the following.
1. Allow X requests from multiple threads, and incorporate external locking.  If we need to poll, we could create a new thread to do the polling, and map any requests that depend on the mapping to be finished to that thread.
2. Create one thread solely for interacting with the X server, but build a more sophisticated command buffer that adds dependencies among commands.  Instead of interacting with the X server directly, users would submit commands to this new interface.  In this case, we could add a dependency for the mapping to be finished on all X requests that use the new tooltip.

Other idea: we currently block for window mapping, but we don't block for window unmapping.

If an unmap is in queue, and we then immediately try to map it again, does xlib just cancel the unmap (and then not send us the MapNotify we're expecting)?

I don't think so. I made a test app that does Unmap+Map+Sync, and we see both events.

#include <stdio.h>
#include <X11/Xlib.h>
#include <X11/Xutil.h>
#include <X11/Xatom.h>

void WaitFor(Display* display) {
  int    end;
  XEvent report;

  end = 0;
  while (!end) {
    XNextEvent(display, &report);
    switch (report.type) {
        case MapNotify:
            printf("MapNotify\n");
            end = 1;
            break;
        case UnmapNotify:
            printf("UnmapNotify\n");
            end = 1;
            break;
        case DestroyNotify:
            printf("DestroyNotify\n");
            end = 1;
            break;
    }
  }

}

int main () {
  Display   *display;
  Window     parent;
  int        x=10,y=10,h=400,w=400;

  display = XOpenDisplay(NULL);

  if (display == NULL) {
    fprintf(stderr, "couldn't connect to X server :0\n");
    return 0;
  }

  parent = XCreateWindow(display, RootWindow(display, 0),
             x, y, w, h, 10, CopyFromParent, CopyFromParent,
             CopyFromParent, 0, 0);
  XSelectInput(display, parent, StructureNotifyMask);

  XMapWindow(display, parent);
  XSync(display, False);

  WaitFor(display);

  XUnmapWindow(display, parent);
  XMapWindow(display, parent);
  XSync(display, False);

  while (1) {
      WaitFor(display);
  }

  return 1;
}

Is it possible that the override-redirect flag for the window is False?  If it is, it would allow window managers to intercept any map request.  We would get MapRequest events instead of MapNotify events, which would explain the infinite loop.  In particular, carefully check this documentation:

XMapWindow: "If the override-redirect of the window is False and if some other client has selected SubstructureRedirectMask on the parent window, then the X server generates a MapRequest event, and the XMapWindow() function does not map the window. Otherwise, the window is mapped, and the X server generates a MapNotify event."

MapRequest Events: "The X server can report MapRequest events to clients wanting information about a different client's desire to map windows. A window is considered mapped when a map window request completes. The X server generates this event whenever a different client initiates a map window request on an unmapped window whose override_redirect member is set to False . Clients initiate map window requests by calling XMapWindow(), XMapRaised(), or XMapSubwindows()."

Override Redirect Flag: "To control window placement or to add decoration, a window manager often needs to intercept (redirect) any map or configure request. Pop-up windows, however, often need to be mapped without a window manager getting in the way. To control whether an InputOutput or InputOnly window is to ignore these structure control facilities, use the override-redirect flag."

The MapRequest would go to the WM. Once it mapped the window, a MapNotify would come back to Chrome. It does mean a hung or misbehaving WM would hang Chrome here.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/56cc0f5cd062625b39f7e4d1f326313ea010383b

commit 56cc0f5cd062625b39f7e4d1f326313ea010383b
Author: erg <erg@chromium.org>
Date: Fri Apr 15 17:47:17 2016

Add a crash for debugging when we get into a bad state.

This will crash chrome whenever we receive a MapNotify outside of our calling XMapWindow().

BUG=381732

Review URL: https://codereview.chromium.org/1886983003

Cr-Commit-Position: refs/heads/master@{#387637}

[modify] https://crrev.com/56cc0f5cd062625b39f7e4d1f326313ea010383b/ui/views/widget/desktop_aura/desktop_window_tree_host_x11.cc
[modify] https://crrev.com/56cc0f5cd062625b39f7e4d1f326313ea010383b/ui/views/widget/desktop_aura/desktop_window_tree_host_x11.h

chromium recent git  segfaults on fedora 23(x86-64).

[1469:1469:0418/002954:FATAL:desktop_window_tree_host_x11.cc(1888)] Check failed: x_map_window_was_called_. Received MapNotify event despite never calling XMapWindow(). (This is debugging state for crbug.com/381732.)
#0 0x557f4fa42118 base::debug::StackTrace::StackTrace()
#1 0x557f4fa556ed logging::LogMessage::~LogMessage()
#2 0x557f5261e2df views::DesktopWindowTreeHostX11::DispatchEvent()
#3 0x557f501fe6b0 ui::PlatformEventSource::DispatchEvent()
#4 0x557f53359bde ui::X11EventSourceGlib::ProcessXEvent()
#5 0x557f533575e9 ui::X11EventSource::ExtractCookieDataDispatchEvent()
#6 0x557f5335764a ui::X11EventSource::DispatchXEvents()
#7 0x557f53359ca3 ui::(anonymous namespace)::XSourceDispatch()
#8 0x7fb44958de3a g_main_context_dispatch
#9 0x7fb44958e1d0 <unknown>
#10 0x7fb44958e27c g_main_context_iteration
#11 0x557f4fa998c3 base::MessagePumpGlib::Run()
#12 0x557f4fa5a332 base::MessageLoop::RunHandler()
#13 0x557f4fa6f4a2 base::RunLoop::Run()
#14 0x557f4f856c9d ChromeBrowserMainParts::MainMessageLoopRun()
#15 0x557f5225653c content::BrowserMainLoop::RunMainMessageLoopParts()
#16 0x557f5206aa79 content::BrowserMainRunnerImpl::Run()
#17 0x557f5206a9b5 content::BrowserMain()
#18 0x557f4fa15147 content::RunNamedProcessTypeMain()
#19 0x557f4fa15223 content::ContentMainRunnerImpl::Run()
#20 0x557f4fa149e7 content::ContentMain()
#21 0x557f4f6423e8 ChromeMain
#22 0x557f4f6423a9 main
#23 0x7fb443bc1580 __libc_start_main
#24 0x557f4f642299 _start

Does if segfault always or randomly?

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/d3c20a16015c13ca35a01a70657c6ec95f85cc55

commit d3c20a16015c13ca35a01a70657c6ec95f85cc55
Author: erg <erg@chromium.org>
Date: Mon Apr 18 20:07:20 2016

Revert "Add a crash for debugging when we get into a bad state."

This reverts commit 56cc0f5cd062625b39f7e4d1f326313ea010383b.

We're actually seeing this crash in the wild. Let's see if we can craft
a workaround to the bug now that we know this.

TBR=danakj@chromium.org
BUG=381732

Review URL: https://codereview.chromium.org/1901813002

Cr-Commit-Position: refs/heads/master@{#387994}

[modify] https://crrev.com/d3c20a16015c13ca35a01a70657c6ec95f85cc55/ui/views/widget/desktop_aura/desktop_window_tree_host_x11.cc
[modify] https://crrev.com/d3c20a16015c13ca35a01a70657c6ec95f85cc55/ui/views/widget/desktop_aura/desktop_window_tree_host_x11.h

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/2c9261719c810fd986b2bb3b1e1206de7e4094f3

commit 2c9261719c810fd986b2bb3b1e1206de7e4094f3
Author: erg <erg@chromium.org>
Date: Mon Apr 18 22:16:12 2016

Record that the window is mapped when we receive a MapNotify event.

Previously, we recorded that we mapped a window after we waited for a
MapNotify event after we called XMapWindow(). While this should
theoretically never happen, we appear to be getting MapNotify events
when we haven't called XMapWindow(). Record that the window is mapped
whenever we get a MapNotify instead so that we at least don't block
waiting for a MapNotify that will never come.

BUG=381732

Review URL: https://codereview.chromium.org/1898953003

Cr-Commit-Position: refs/heads/master@{#388040}

[modify] https://crrev.com/2c9261719c810fd986b2bb3b1e1206de7e4094f3/ui/views/widget/desktop_aura/desktop_window_tree_host_x11.cc

Okay, I've resolved the issue in Enlightenment, and I can describe the changes which must be made in order to fix chromium:

Chromium tooltips in X11 are override-redirect windows. Override-redirect windows do not need to wait for the window manager/compositor to (un)map them--(un)mapping them in the client (un)maps them. This means that any waiting on (un)map events for override-redirects is going to do nothing but trigger bugs when running in wms/compositors which call (un)map on these types of windows since their mapped state is based on nothing but the client's policy.

Essentially, remove any MapNotify/UnmapNotify handling for these types of windows and the bug will no longer occur. Xorg handles requests synchronously, so calling XMapWindow and then immediately acting upon the window as if it were mapped is correct and accurate.

see https://tronche.com/gui/x/xlib/window/map.html for some details about override-redirect mapping.

@235: OK, that makes sense.

Is there a way to disable tooltips completely?

some
Chromium 49.0.2623.108 Built on Ubuntu 16.04
weston 1.9.0

ERROR:browser_main_loop.cc()] Gtk: cannot open display 

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/28bb70402ddc4e68963f536388730c63598f8d65

commit 28bb70402ddc4e68963f536388730c63598f8d65
Author: erg <erg@chromium.org>
Date: Mon Apr 25 21:44:50 2016

x11: Don't wait on a MapNotify on override-redirect windows.

Some window managers do not send MapNotify on override-redirect
windows. Enlightenment doesn't send one, XFCE does, and I don't know
which behaviour is more common.

This makes mapping resilient against whether we would have received a
MapNotify message on override-redirect window. On override-redirect
windows, we immediately trigger the code that would run in the future
MapNotify handler, and ignore it in the future MapNotify message if it
is already run.

BUG=381732

Review URL: https://codereview.chromium.org/1896363004

Cr-Commit-Position: refs/heads/master@{#389572}

[modify] https://crrev.com/28bb70402ddc4e68963f536388730c63598f8d65/ui/views/widget/desktop_aura/desktop_window_tree_host_x11.cc
[modify] https://crrev.com/28bb70402ddc4e68963f536388730c63598f8d65/ui/views/widget/desktop_aura/desktop_window_tree_host_x11.h

[ just a drive-by comment on the commit message ]

"Some window managers do not send MapNotify on override-redirect
windows. Enlightenment doesn't send one, XFCE does,"

^ this doesn't make sense since it doesn't depend on the WM at all. The X11 protocol is quite clear about this, and the implementation in the X server seems correct AFAICT. For override-redirect windows the client issuing the MapRequest will always receive a MapNotify event.

@rtcm: Indeed. zmike (#235) explained it out-of-band, and as I understand it, the race is:
  - client maps pop-up
  - WM receives MapNotify
  - client unmaps pop-up
  - WM calls MapWindow in response to MapNotify, despite it being override-redirect
  - client maps pop-up again
  - no MapNotify is ever received

erg's commit in #239 thus seems to resolve the catastrophic failure mode (wait forever for a MapNotify which will never arrive) in the correct way (override-redirect windows will be mapped by the time the next request is processed), but without resolving the fundamental failure of the client's desired map state being out of sync with the server's actual map state.

Given that, and the prevalence of WMs which trip this failure in the wild, I'd suggest doing away with the unmapped-but-created state for override-redirect windows, and destroying the window entirely rather than unmapping it, with a new window being created when it comes time to remap it.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/64a7c6401449a843118d9fc208798674a5a8c7ea

commit 64a7c6401449a843118d9fc208798674a5a8c7ea
Author: erg <erg@chromium.org>
Date: Wed Apr 27 18:59:46 2016

Revert of x11: Don't wait on a MapNotify on override-redirect windows. (patchset #3 id:40001 of https://codereview.chromium.org/1896363004/ )

Reason for revert:
Patch suspected to cause blank sublist on menus.

BUG=606661

Original issue's description:
> x11: Don't wait on a MapNotify on override-redirect windows.
>
> Some window managers do not send MapNotify on override-redirect
> windows. Enlightenment doesn't send one, XFCE does, and I don't know
> which behaviour is more common.
>
> This makes mapping resilient against whether we would have received a
> MapNotify message on override-redirect window. On override-redirect
> windows, we immediately trigger the code that would run in the future
> MapNotify handler, and ignore it in the future MapNotify message if it
> is already run.
>
> BUG=381732
>
> Committed: https://crrev.com/28bb70402ddc4e68963f536388730c63598f8d65
> Cr-Commit-Position: refs/heads/master@{#389572}

TBR=danakj@chromium.org,thomasanderson@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=381732

Review-Url: https://codereview.chromium.org/1931583002
Cr-Commit-Position: refs/heads/master@{#390140}

[modify] https://crrev.com/64a7c6401449a843118d9fc208798674a5a8c7ea/ui/views/widget/desktop_aura/desktop_window_tree_host_x11.cc
[modify] https://crrev.com/64a7c6401449a843118d9fc208798674a5a8c7ea/ui/views/widget/desktop_aura/desktop_window_tree_host_x11.h

Reverted first attempt at fixing since it was leading to blank pop ups on amd drivers, but worked on nvidia drivers.

As danakj@ mentioned in the CR when I reverted:

> > I guess we need to wait for MapNotify before rendering if it's going to come,
> > but not if it's not? What a story.
>
> One possibility is to damage the window when we hear it maps so we re-render it
> or something. Ugh :/

Really glad to see this is currently being addressed.  Reviewed the discussion since Comment 184 and we are definitely still talking about the same bug that I observed and reported on back in 2015.  I mentioned this bug in a thread on cros-discuss two days ago.  Will be happy to test any committed patches for confirmation of the solution, when you think you have a good one.  Thanks!

@241: "I'd suggest doing away with the unmapped-but-created state for override-redirect windows, and destroying the window entirely rather than unmapping it, with a new window being created when it comes time to remap it."

Doing that properly would be difficult. The cross platform code assumes that the native window is created hidden, and then is set up before being shown. Modifying the cross platform code to work differently, or building the cache of  properties/shapes/_net_wm_desktop events would be a lot of work.

I'm going to try Dana's idea always damaging the window on MapNotify on override-redirect windows and see if that fixes the failure on amd drivers.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/a23e0eae44653ab9f132d454ac6488c8c8005479

commit a23e0eae44653ab9f132d454ac6488c8c8005479
Author: erg <erg@chromium.org>
Date: Fri Apr 29 21:51:13 2016

[reland] x11: Don't wait on a MapNotify on override-redirect windows.

[This reland should theoretically fix a case where timing issues on
AMD drivers appear to cause a blank window by forcing a redraw when
we are an override-redirect window and receive a MapNotify.]

Some window managers do not send MapNotify on override-redirect
windows. Enlightenment doesn't send one, XFCE does, and I don't know
which behaviour is more common.

This makes mapping resilient against whether we would have received a
MapNotify message on override-redirect window. On override-redirect
windows, we immediately trigger the code that would run in the future
MapNotify handler, and ignore it in the future MapNotify message if it
is already run.

BUG=381732,606661
First Review URL: https://codereview.chromium.org/1896363004

Review-Url: https://codereview.chromium.org/1933923002
Cr-Commit-Position: refs/heads/master@{#390773}

[modify] https://crrev.com/a23e0eae44653ab9f132d454ac6488c8c8005479/ui/views/widget/desktop_aura/desktop_window_tree_host_x11.cc
[modify] https://crrev.com/a23e0eae44653ab9f132d454ac6488c8c8005479/ui/views/widget/desktop_aura/desktop_window_tree_host_x11.h

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/e6184cdf538895d1ca804d1c2abb2474ec1abd54

commit e6184cdf538895d1ca804d1c2abb2474ec1abd54
Author: erg <erg@chromium.org>
Date: Mon May 02 17:55:36 2016

Revert of x11: Don't wait on a MapNotify on override-redirect windows. (patchset #3 id:40001 of https://codereview.chromium.org/1933923002/ )

Reason for revert:
Forcing a draw didn't actually fix the blank submenu issue.

Original issue's description:
> [reland] x11: Don't wait on a MapNotify on override-redirect windows.
>
> [This reland should theoretically fix a case where timing issues on
> AMD drivers appear to cause a blank window by forcing a redraw when
> we are an override-redirect window and receive a MapNotify.]
>
> Some window managers do not send MapNotify on override-redirect
> windows. Enlightenment doesn't send one, XFCE does, and I don't know
> which behaviour is more common.
>
> This makes mapping resilient against whether we would have received a
> MapNotify message on override-redirect window. On override-redirect
> windows, we immediately trigger the code that would run in the future
> MapNotify handler, and ignore it in the future MapNotify message if it
> is already run.
>
> BUG=381732,606661
> First Review URL: https://codereview.chromium.org/1896363004
>
> Committed: https://crrev.com/a23e0eae44653ab9f132d454ac6488c8c8005479
> Cr-Commit-Position: refs/heads/master@{#390773}

TBR=danakj@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=381732,606661

Review-Url: https://codereview.chromium.org/1934413002
Cr-Commit-Position: refs/heads/master@{#390989}

[modify] https://crrev.com/e6184cdf538895d1ca804d1c2abb2474ec1abd54/ui/views/widget/desktop_aura/desktop_window_tree_host_x11.cc
[modify] https://crrev.com/e6184cdf538895d1ca804d1c2abb2474ec1abd54/ui/views/widget/desktop_aura/desktop_window_tree_host_x11.h

Passing to Tom.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/89f356e5bb13b81624a432a149d18e75694676c9

commit 89f356e5bb13b81624a432a149d18e75694676c9
Author: thomasanderson <thomasanderson@google.com>
Date: Mon Jun 13 18:11:36 2016

X11: Wait for UnmapNotify before trying to remap

A speculative fix for a suspected race condition in which we wait for a
MapNotify that will never come.

BUG=381732

Review-Url: https://codereview.chromium.org/2057333002
Cr-Commit-Position: refs/heads/master@{#399484}

[modify] https://crrev.com/89f356e5bb13b81624a432a149d18e75694676c9/ui/events/platform/x11/x11_event_source.cc
[modify] https://crrev.com/89f356e5bb13b81624a432a149d18e75694676c9/ui/events/platform/x11/x11_event_source.h
[modify] https://crrev.com/89f356e5bb13b81624a432a149d18e75694676c9/ui/views/widget/desktop_aura/desktop_window_tree_host_x11.cc
[modify] https://crrev.com/89f356e5bb13b81624a432a149d18e75694676c9/ui/views/widget/desktop_aura/desktop_window_tree_host_x11.h

Could anyone who is experiencing this issue try the change in #249?

The change in comment 249 is in Chrome 53.0.2767.0 or newer.

I have a machine that is still affected by this issue, it takes a while to show up, but I should be able to tell you by the end of the day whether 53.0.2767.0 or newer still triggers that issue.

The workaround that I've found to reliably make the issue go away seems to be, to install my OS (debian, Ubuntu, whatever) using the Desktop Installer and let it take care of installing Gnome, Unity, etc.  I haven't tried switching back to Enlightenment.  So far I have two machines that both had this issue, and it's resolved for me since I wiped the disk clean and reinstalled from scratch without trying to build up my DE from a bare image.

Using Chrome Stable channel 51.0.2704.84 (64-bit)

This explains for me why so few seem to be affected by this issue but it follows me around, I'm not sure what the installer does that I don't do, but most people are probably not building their environment from a bare image without using tasksel or similar package-group installation scheme.

I will try to repro there, on the machine that is still affected, and get back to you by tomorrow hopefully.

I'm tired of fighting. Returned E20 -> E17 (Bodhi Linux). There are no problems :(
rus: Я устал бодаться. Вернулся Е20 -> Е17 (Bodhi Linux). Тут нет проблем :( 

Sad ...

How do I install Chrome 53.0.2767.0? Is it Canary?

It says "Chrome Canary is currently not available on the linux platform."

Give it a few days to reach the dev channel which is available for Linux.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/89f356e5bb13b81624a432a149d18e75694676c9

commit 89f356e5bb13b81624a432a149d18e75694676c9
Author: thomasanderson <thomasanderson@google.com>
Date: Mon Jun 13 18:11:36 2016

X11: Wait for UnmapNotify before trying to remap

A speculative fix for a suspected race condition in which we wait for a
MapNotify that will never come.

BUG=381732

Review-Url: https://codereview.chromium.org/2057333002
Cr-Commit-Position: refs/heads/master@{#399484}

[modify] https://crrev.com/89f356e5bb13b81624a432a149d18e75694676c9/ui/events/platform/x11/x11_event_source.cc
[modify] https://crrev.com/89f356e5bb13b81624a432a149d18e75694676c9/ui/events/platform/x11/x11_event_source.h
[modify] https://crrev.com/89f356e5bb13b81624a432a149d18e75694676c9/ui/views/widget/desktop_aura/desktop_window_tree_host_x11.cc
[modify] https://crrev.com/89f356e5bb13b81624a432a149d18e75694676c9/ui/views/widget/desktop_aura/desktop_window_tree_host_x11.h

Has anyone affected by this issue gotten a chance to try with 53.0.2767.0 or newer?

Running Chrome Dev for a week. This exact issue hasn't hit me. But there were some other strange hang issue, but only one tab becomes unresponsive.

I've partly read through this thread and think I'm seeing this consistently when running certain browser tests using xvfb. Basically, my test is hanging and gdb shows the UI thread waiting with the following stack trace:
(gdb) bt
#0  0xf76fc440 in __kernel_vsyscall ()
#1  0xf647c01b in poll () from /lib/i386-linux-gnu/libc.so.6
#2  0xf61ed3a8 in ?? () from /usr/lib/i386-linux-gnu/libxcb.so.1
#3  0xf61ef394 in xcb_wait_for_event ()
   from /usr/lib/i386-linux-gnu/libxcb.so.1
#4  0xf7197447 in _XReadEvents () from /usr/lib/i386-linux-gnu/libX11.so.6
#5  0xf7195727 in XWindowEvent () from /usr/lib/i386-linux-gnu/libX11.so.6
#6  0x0d809431 in ui::X11EventSource::BlockUntilWindowMapped(unsigned long) ()
#7  0x0d446bfd in views::DesktopWindowTreeHostX11::MapWindow(ui::WindowShowState) ()
#8  0x0d4469ea in views::DesktopWindowTreeHostX11::ShowWindowWithState(ui::WindowShowState) ()
#9  0x0d4400b2 in views::DesktopNativeWidgetAura::ShowWithWindowState(ui::WindowShowState) ()
#10 0x0d42c89a in views::Widget::Show() ()
#11 0x0e3c40cf in BrowserView::Show() ()
#12 0x0e310a50 in StartupBrowserCreatorImpl::OpenTabsInBrowser(Browser*, bool, std::vector<StartupTab, std::allocator<StartupTab> > const&) ()

If there's anything I can do to help, let me know.

I have this issue on 2 separate systems at the moment. I find it most reproducible when using more than one window. Upgrading both right now.

49.0.2623.87-r1 to 53.0.2767.4

and

50.0.2661.75 to 53.0.2767.4

amistry@ Is the version you're running at least 53.0.2767.0?

My checkout is at 53.0.2784.0 (r402704). I'm running browser_tests using ./testing/xvfb.py and a 32-bit release+dchecks build.

#265 Is there any particular gtest_filter you're using?

GN args:
is_component_build = false
is_debug = false
use_goma = true
dcheck_always_on = true
enable_nacl = true
target_cpu = "x86"

command line:
./testing/xvfb.py out/Release.gn ./out/Release.gn/browser_tests --gtest_filter=ChromeServiceWorkerFetchPPAPITest.SameOrigin

It passes the first time I run. But every subsequent run fails until I rebuild.

Thanks.  I'll try to see if I can repro with a fresh checkout.

I'm running Version 51.0.2704.103 (64-bit) for some time now (weeks?) and I don't have a problem.

Perhaps what I hit earlier was a different bug?
Or maybe I set too many custom flags in the past?

Sorry, I can't help.

I have a linux machine (Ubuntu) with 52.0.2729.3 (which is older than unstable_current, should be 53.0.2783.2, and older than 53.0.2767.0).  This machine definitely was experiencing the issue described in this thread.  I will keep using the older version and spend some time on here in the next couple of days, until I can confirm the problem is still here, extant.  I have downloaded a deb marked unstable_current from today's builds on the dev channel to install once I am able to confirm the repro.

I have other workstations that are not ever affected by this bug after days and weeks, it seems to be something environmental (I think I vaguely understand about the compositing window managers), I won't speculate about that any further but, I should be able to confirm the fix within a few days if it has been fixed.  So far I am not able to repro after about 15 minutes but it varies about how long it takes to trigger the issue.

Could be anywhere up to a whole day.  Tends to cluster and usually crashes/affects me more frequently around times of heavy usage.

Will report back when I am able to reproduce the issue again, hopefully just this one last time.

Come to think of it, we have to establish specific environment where older builds were getting stuck -- Xrg version, WM version.

There's no point asking users if problem disappeared, because there's no way to attribute that to change in chromium vs a change in WM.

In this case, we should wait for this build to reach stable.

In my situation I'm seeing it on two separate chromium versions on 2 separate desktops and one other google-chrome version on one of those same desktops from gentoo. I've only moderately used the new versions but so far so good. I was able to lock the old versions within about 30 minutes of browsing one of these being my main laptop so I should be able to assert whether or not it's still present within another day or two for sure. I have tried not to update too much else but probably did a few things because one version needed a newer gzip and I wasn't sure what the build problem was exactly on that machine so a few system libs were updated/rebuilt but I tried to avoid anything X or graphics related.

Nonetheless I will be glad if we can get someone who has seen this problem to say this upgrade caused it to go away.

So far I have been unable to reproduce the problem (due to time constraints on my day) but, I have not installed the updated version and I will wait until I see the problem come back.

I've spent extensive time with chromium-53.0.2774.3 on a previously affected system and have not had the issue. 

I've spent a moderate amount of time with chromium 53.0.2767.4 on a different previously affected system and have not had the issue.

On the third previously affected system I have chromium 53.0.2767.4 also and have not had the issue but have only spent a little browsing time with it.

Prior to upgrading I could cause the lockup usually within 20 minutes by opening  a second window and hovering over elements in google hangouts windows. I am unable to cause such a lockup with these latest builds.

I'm not able to freeze whole Chrome either.

But I'm able to freeze specific tabs. I.e. sometimes I have to reopen the tab as otherwise my cursor is not changing, and it's not scrollable.
Don't know if it's related or not. At least I don't see frozen tooltips.

Overall, it's much much better! Having to close one tab is negligible in comparison to having to close whole browser, potentially loosing all work.

@thomasanderson: I've not been able to reproduce this since. I do still see corrupted tooltips (mostly displaying old content with new size), which I'd say is a symptom of the same issue, but no freezes.

#277 - can you make sure this issue is also filed?

#278 - issue #442111

No repros in a month. Let's move this to Fixed and reopen if we get any reports of the whole chrome hang.

It has been working for me for some time now as well.