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

Issue 381732 link

Starred by 79 users

Issue metadata

Status: Fixed
Owner:
Closed: Aug 2016
Cc:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 2
Type: Bug



Sign in to add a comment

The browser hangs when showing tooltips in Compositing WMs (Gnome Shell, Enlightenment)

Reported by charles....@gmail.com, Jun 6 2014

Issue description

Chrome Version (from the about:version page): 37.0.2031.2
Is this the most recent version: Yes
OS + version: Arch Linux
CPU architecture (32-bit / 64-bit): 64-bit
Window manager: Gnome Shell 3.12.2
URLs (if relevant): N/A
Behavior in Linux Firefox: N/A
Behavior in Windows Chrome (if you have access to it): N/A

What steps will reproduce the problem?
1. Use Chrome normally, hovering over links and UI element to show their tooltips

What is the expected result?


What happens instead?
A empty tooltip will appear and it eventually will make Chrome hang.
It also will appear over any other window.

Please provide any additional information below. Attach a screenshot
and backtrace if possible.

 
Captura de tela de 2014-06-06 13:52:45.png
123 KB View Download
Showing comments 184 - 283 of 283 Older

Comment 184 by van...@gmail.com, Mar 24 2016

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

Comment 186 Deleted

Owner: e...@chromium.org
this code seems to be largely from https://chromiumcodereview.appspot.com/10828133 so bouncing to erg@
erg@, please see c164.

Comment 189 by e...@chromium.org, Mar 29 2016

Cc: sadrul@chromium.org thomasanderson@google.com
Owner: ----
Status: Available (was: Untriaged)
(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.

Comment 190 by van...@gmail.com, Apr 2 2016

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?

Comment 191 by van...@gmail.com, Apr 2 2016

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

Comment 192 by van...@gmail.com, Apr 2 2016

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?

Comment 194 by van...@gmail.com, Apr 2 2016

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.

Comment 203 by dim...@gmail.com, Apr 4 2016

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.

Comment 208 by dim...@gmail.com, Apr 4 2016

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.
Summary: The browser hangs when showing tooltips in Compositing WMs (Gnome Shell, Enlightenment) (was: The browser hangs when showing tooltips on Gnome Shell 3.12)
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.


Comment 226 by e...@chromium.org, Apr 14 2016

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.
Project Member

Comment 230 by bugdroid1@chromium.org, Apr 15 2016

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

Comment 231 by kuh...@gmail.com, Apr 17 2016

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?
Project Member

Comment 233 by bugdroid1@chromium.org, Apr 18 2016

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

Project Member

Comment 234 by bugdroid1@chromium.org, Apr 18 2016

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.

Comment 236 by e...@chromium.org, Apr 21 2016

Owner: e...@chromium.org
Status: Assigned (was: Available)
@235: OK, that makes sense.

Comment 237 by van...@gmail.com, Apr 25 2016

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 
Project Member

Comment 239 by bugdroid1@chromium.org, Apr 25 2016

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.
Project Member

Comment 242 by bugdroid1@chromium.org, Apr 27 2016

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

Comment 243 by e...@chromium.org, Apr 28 2016

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 :/

Comment 244 by yeb...@gmail.com, Apr 29 2016

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!

Comment 245 by e...@chromium.org, Apr 29 2016

@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.
Project Member

Comment 246 by bugdroid1@chromium.org, Apr 29 2016

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

Project Member

Comment 247 by bugdroid1@chromium.org, May 2 2016

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

Owner: thomasanderson@chromium.org
Passing to Tom.
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 ...

Comment 255 by van...@gmail.com, Jun 14 2016

How do I install Chrome 53.0.2767.0? Is it Canary?

Comment 256 by van...@gmail.com, Jun 14 2016

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.
Has anyone affected by this issue gotten a chance to try with 53.0.2767.0 or newer?

Comment 260 Deleted

Comment 261 by van...@gmail.com, Jun 28 2016

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.

Comment 269 by dim...@gmail.com, Jun 30 2016

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.

Comment 271 by dim...@gmail.com, Jul 1 2016

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.

Comment 272 by van...@gmail.com, Jul 1 2016

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.

Comment 276 by van...@gmail.com, Jul 19 2016

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 

Comment 280 by e...@chromium.org, Aug 18 2016

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

Comment 281 by kar...@gmail.com, Aug 18 2016

It has been working for me for some time now as well.
Created another issue, since the root cause is still not fixed:
https://bugs.chromium.org/p/chromium/issues/detail?id=877508

Does nobody from chrome developers use Gnome 3?
Cc: thomasanderson@chromium.org phanindra.mandapaka@chromium.org
 Issue 877508  has been merged into this issue.
Showing comments 184 - 283 of 283 Older

Sign in to add a comment