Message is "Restore pages? Chrome didn't shut down correctly. [Restore button]"

and it just crashed (I resumed my laptop from suspend to ram after few hours of it sleeping and saw that google chrome crashed again)

This log could be related to crash:
[1:1:0100/000000:ERROR:broker_posix.cc(41)] Invalid node channel message

I'm getting it just before or just after a crash (can't tell exactly which case is that because google chrome doesn't output anything else on terminal at that time / at restart).

Dec 06 15:18:44 [1:1:0100/000000:ERROR:broker_posix.cc(41)] Invalid node channel message

Definitely related. Just crashed again and there is such message on stdout.

I have been able to reliably force this crash with this steps:
1. Open main chromium window with reddit main page (https://www.reddit.com).
2. Open incognito window and move it to another desktop (so it is not brought to front when sending links to it).
3. From main window (reddit main page) open several (~7) links to comment posts in rapid succesion (every ~1 second) by right clicking "comments" links and selecting "Open in incognito window".
After about 10 seconds all browser windows will close, may reopen with some of previously opened links.
Every time one or two of these errors will be printed out:
"ERROR:backend_impl.cc(1033)] Critical error found -8"
"ERROR:desktop_window_tree_host_x11.cc(1885)] Not implemented reached in void views::DesktopWindowTreeHostX11::MapWindow(ui::WindowShowState)"                                     
"ERROR:broker_posix.cc(41)] Invalid node channel message"

This issue was introduced in 55.0.2883.75-1, downgrading to previous release (in my case 54.0.2840.100-1) does not manifest this behaviour.
I am using chromium package from "Extra" repositiory on Arch Linux.

unable to reproduce this issue with the ubuntu 14.04 with chrome version 55.0.2883.75 with the steps mentioned in the comment#0.

arekm@ could you try this scenario with clean profile without any apps/extensions and let us know your observations. 

@kkaluri: I can reproduce it with fresh profile.

1) 
rm -rf empty
mkdir empty
google-chrome --user-data-dir=$(pwd)/empty

browser window appears on desktop X

2) switch to different desktop, Y (important)
3) run from terminal
 google-chrome --user-data-dir=$(pwd)/empty https://www.google.com/

Normally text like "Created new window in existing browser session." would appear and page would load on main (previous) google chrome window but NOT in this case. For me nothing happens for longer period. While on taskbar I see that page did not load on main google chrome window.
4) wait for 20-30 seconds not leaving Y desktop
5) switch to desktop X
6) google chrome crashes and shows restore button. On terminal:

"
[...]
Killed
"

Using xserver 1.19, xorg libinput 0.22 and kde 4 here.

Also reproduced on Fedora 25 with xserver 1.19 + kde5 (without wayland running) with comment #7 scenario.

The important part here is that this happens when the window with the new tabs isn't focused. My reproducer is this:

1. use a window manager that ignores _NET_ACTIVE_WINDOW requests from chrome (my usecase is opening a bunch of tabs from a desktop RSS reader and the default behaviour of chrome is to bring itself into focus immediately, so my window manager ignores this explicitly)
2. switch to another desktop
3. open a bunch of links in command line via "google-chrome http://something"
4. wait a few seconds
5. boom, chrome is restarted without a crash dump or anything

An interesting (imo) observation is that the command line invocation normally returns in a seconds and says "Created new window in existing browser session." but if chrome is out of focus, it just waits and then becomes the new session. As if it deliberately killed the existing session.

(And just for the record, I can confirm this as a chrome 55 regression. This wasn't happening with chrome 54. I would know, I reproduce this accidentally several times a day. Annoying as hell, to be honest. :-))

Oh and just in case someone wants to argue that my WM shouldn't just ignore chrome's requests to come into focus, here's a link to the relevant spec: https://specifications.freedesktop.org/wm-spec/wm-spec-latest.html#idm140200472702304

Notably: "the Window Manager may decide to refuse the request (either completely ignore it, or e.g. use _NET_WM_STATE_DEMANDS_ATTENTION)."

FWIW I am also seeing this. I don't ignore _NET_ACTIVE_WINDOW; seems like the receiving chrome window's process is still paging in (...sigh), although the wm indicates focus has in fact been assigned.

I also have this problem: https://bugs.chromium.org/p/chromium/issues/detail?id=673117

Before this all happened (when I installed chrome), I got an SELinux denial message against chrome (forgot what it said), the result was Chrome couldn't load any pages, the entire webpage box becomes a solid indigo color. (No "Aw, snap!" message). I didn't know if chrome would die at that time.

After closing chrome allowing google-chrome from SElinux like this:

grep chrome /var/log/audit/audit.log | audit2allow -M mypol
semodule -i mypol.pp

The above symptoms happened after starting chrome. Even deleting the mypol.pp and mypol.te files SELinux generated didn't help.

 Issue 673117  has been merged into this issue.

For what it's worth, as of 55.0.2883.87 this seems to at least be less common. (I'm still being cautious with external URLs. :)

My random Chrome deaths on Ubuntu 16.04 started with Chrome 54 (~1-2 times a week on two very different machines), but now the crashes seem to be more frequent with Chrome 55.  I generally see nothing in my system logs.  The crashes typically happen when navigating or opening a new tab.

Guess it's just "appears less common"; 55.0.2883.87 just aborted the same way.

With 55.0.2883.87 still aborting I think I found the main cause of this problem.
I was using eclipse's internal web browser, searched for some topic with a lot of hits (e.g. 'foo') and the entire program crashed with a segmentation fault too.

This came from the crash log:

# Problematic frame:
# C  [libwebkitgtk-3.0.so.0+0xb0e287]

(apparently the internal web browser uses webkit layout engine.)

On my computer the webkit3 version was 2.4.9-1. Updating this package to 2.4.9-5 broke every gnome package that connects to the internet and/or renders HTML e.g. yelp (gnome's help program) and gnome-control-center, now they don't start and only an OS reinstall can fix that. Since these can't start it's unlikely that chrome will work on my computer at this point.


Just in case you're curious, here is the error message when you try to start them:

 symbol lookup error: /lib64/libwebkitgtk-3.0.so.0: undefined symbol: _gst_tag_list_type


Anyway, the only solution I can see right now is using a library with either a different GUI toolkit (konqueror uses Qt and has KHTML/webkit renderers and it works fine) or a library specifically designed for Blink. This Gtk/webkit library appears to be problematic.

coolchar...@: Wrong bug. Unrelated. (Your libwebkitgtk-3.0.so.0 was linked with other gstreamer library than you have in system. Try to upgrade both, gtk-webkit and gstreamer packages.)

previous comments suggest that chromium is affected too so what we have to do is compiling chromium with debug information because in this case we can see the exact error location in the stack trace.

I hope that somebody here can do that because I currently don't have the resources to build such a big project.

Thank you for providing more feedback. Adding requester "kkaluri@chromium.org" for another review and adding "Needs-Review" label for tracking.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

I just saw a

kernel: traps: Chrome_FileThre[29659] trap invalid opcode ip:556e343663fd sp:7f49fe4d06c0 error:0 in chrome[556e3229d000+6612000]

Chrome 55.0.2883.87 (64-bit)
xubuntu 16.04.1 / xfce4 / no compositor
Intel(R) Core(TM) i7-2620M CPU @ 2.70GHz
HP EliteBook 8460p / AMD Radeon HD 6470M / default open source drivers

Any news from chrome devs? Chrome 55.0.2883.87 doesn't even bother sending a  _NET_ACTIVE_WINDOW request any more. :-(

Good news everyone, Chrome 55.0.2883.87 doesn't crash on KDE Plasma 4.10.5 (using in-the-box qtwebkit 2.3.4), so now we know this is a chromium-webkitgtk3 issue, at least on Gnome 3.8.4 with in-the-box webkitgtk3 2.0.4 (which BTW I rolled back on my system, so no gstreamer errors anymore). :)

A side effect though, is that on Gnome, chrome segfaults more quickly, after ~5 seconds.

I don't know if newer Gnome versions fix their webkitgtk3 problem though, if that's the faulty part (or maybe it's chromium itself).

Tested fresh stable google-chrome 56.0.2924.76 x86_64 and the issue is easy to reproduce :/

Starting chrome on my machine now, Kwallet (KDE's keyring) immediately prompted for the password for chrome's secret data (e.g. passwords) which it told me to make in the middle of chrome's first KDE session.

I never saw a similar prompt for Seahorse (GNOME's keyring). 

Perhaps Chrome on gnome isn't identifying Seahorse properly so it segfaults? (after using KDE: immediately; before: "randomly", it was probably it's first time storing secret data, but doesn't know where to store it.

But I can't seem to reproduce the bug by not typing the password in kwallet (Doesn't crash). I do hope this nasty bug gets fixed...

> Good news everyone, Chrome 55.0.2883.87 doesn't crash on KDE Plasma 4.10.5
> (using in-the-box qtwebkit 2.3.4), so now we know this
> is a chromium-webkitgtk3 issue

Using procedure from comment #7 ? If no then check using it.

> Using procedure from comment #7 ? If no then check using it.

And here are the results in the attached text file.

The strange part was I got a GetDisplayDevice error on KDE and Chrome is still running... The same error on GNOME and then Chrome got killed.

Deleted: chrome-runs.txt 3.1 KB

chrome-runs.txt 3.1 KB View Download

Forgot to add this:

gnome 3: #4
    # Now we will test if this seahorse thing is causing a problem.
    Make clean profile
$ google-chrome --user-data-dir=./empty
    Chrome opens
    Tried to sign in chrome, was too slow & got segfault.
$ google-chrome --user-data-dir=./empty  # Tried again
    Chrome starts
    Attempted to sign in chrome *quickly*
    Username/password correct - Got this on terminal while chrome was at the loading screen:
[24:24:0129/205852:ERROR:KeyboardEventManager.cpp(344)] Not implemented reached in static bool blink::KeyboardEventManager::currentCapsLockState()
Segmentation fault
$

Signed in another chrome account via Kwallet and everything went normally.

Hey, Firefox 51 isn't working on KDE 4 either... what's wrong with these browsers? >.<

ar...@: Try running:

google-chrome --user-data-dir=./empty --password-store=basic

with an clean profile. I was able to sign in with this command.

If it works on your end, then --password-store=gnome has a problem.

I am unable to reproduce the problem with the steps in comment #7 or #32.

I think there are multiple different issues being discussed here. For those who correlate the crash with gnome-keyring, can you check what version of the library libsecret you have on your system?

@cfrussios: About #7. On what distribution, windows manager etc did you test? I could try fresh install of fedora core and try to get more easy way for others to reproduce.

I haven't seen a single crash with Chrome 56 (my crashes in Comment 18, 24), so some of this may already be solved.

I'm now on 56.0.2924.87-1 and scenario from #9 is as reproducible as ever.

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

commit 683596645abbc42f0c20768c1579a578f5b36553
Author: bsep <bsep@chromium.org>
Date: Thu Mar 09 22:31:17 2017

Fix opaque frame popup titlebar not being painted.

R=pkasting@chromium.org,thomasanderson@chromium.org
BUG= 695473 , 670959 

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

[modify] https://crrev.com/683596645abbc42f0c20768c1579a578f5b36553/chrome/browser/ui/views/frame/opaque_browser_frame_view.cc

Please ignore the cl in #41, I added this bug number to that cl on accident.

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

commit 662c24fc6debb33ee34a927d21dc26154b8973d6
Author: thomasanderson <thomasanderson@google.com>
Date: Fri Mar 10 17:54:00 2017

Avoid blocking while mapping an X11 window

For most window managers, calling XMapWindow causes a corresponding
MapNotify event to fire, indicating it is ready for drawing. Since this
usually happens immediately, but asynchronously, chromium previously
blocked the UI thread until it got this event, to avoid calling any
further X11 commands on the window until it was ready.

Unfortunately, not all window managers immediately map the window
after a MapRequest.  For example, the i3 window manager will not map
the created window while you're in fullscreen mode (i.e. youtube
video). This means chromium blocks indefinitely until the user
manually exits out of fullscreen mode.

The fix here is to avoid blocking, since we cannot make the assumption
that we'll get a MapNotify event quickly. By simply not blocking on
window map, we create two issues.

The first issue occurs when dragging tabs outside a window to create a
new one. The newly created window would fail to size itself properly
according to the space given to it by the window manager. This was
because the delayed_resize_task_ would get cancelled by SetBounds during
the time the thread would have otherwise been blocked.

This issue was fixed by only cancelling the task when the bounds changed
in that function, since that's the only time it will call OnHostResized
itself.

The second issue occurs during TooltipControllerTests, where a tooltip
is shown/hidden, and then immediately calls IsVisible() on the
widget (which eventually calls it on the underlying native
window). Since the mapping is now async, IsVisible() was false until
MapNotify was called.

The fix for this was to keep track of an additional variable for when we
are waiting for a MapNotify event, and using that to make IsVisible()
true during this time (after calling MapWindow, and before getting
MapNotify).

BUG= 505669 , 670959 

patch from issue 2329323002 at patchset 120001 (http://crrev.com/2329323002#ps120001)

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

[modify] https://crrev.com/662c24fc6debb33ee34a927d21dc26154b8973d6/chrome/browser/extensions/extension_commands_global_registry_apitest.cc
[modify] https://crrev.com/662c24fc6debb33ee34a927d21dc26154b8973d6/chrome/browser/ui/views/passwords/manage_passwords_bubble_view_interactive_uitest.cc
[modify] https://crrev.com/662c24fc6debb33ee34a927d21dc26154b8973d6/chrome/browser/ui/views/ssl_client_certificate_selector_browsertest.cc
[modify] https://crrev.com/662c24fc6debb33ee34a927d21dc26154b8973d6/ui/events/platform/x11/x11_event_source.cc
[modify] https://crrev.com/662c24fc6debb33ee34a927d21dc26154b8973d6/ui/events/platform/x11/x11_event_source.h
[modify] https://crrev.com/662c24fc6debb33ee34a927d21dc26154b8973d6/ui/views/widget/desktop_aura/desktop_window_tree_host_x11.cc
[modify] https://crrev.com/662c24fc6debb33ee34a927d21dc26154b8973d6/ui/views/widget/desktop_aura/desktop_window_tree_host_x11.h

Cleaning up "Needs-Review" label as we are not using this label for triage. Ref  bug 684919 

Well, I tested again on Chrome 57. and it crashed again. But before I go into details, I want to say that I don't update my linux system (for unrelated reasons) and so I don't know if I upgrade from GNOME 3.8 to 3.14 my problem will vanish.

However, the workaround I was using for weeks now (--password-store=basic) is still working. So if this thread really is about active windows, you may have solved that bug now.

By the way, I'm interested to know how you guys figured out it was an active window bug (I'm still a debugging novice).

I don't want to trigger spam filters again so I'll keep this short.

58.0.3029.81 linux x86_64 - problem not fixed and easy to reproduce here (no idea if comment #43 is merged into M58 and if it is then it doesn't fix problem reported in this bug)

I've been following this bug for a long time; I'm pretty sure it's the reason I couldn't upgrade past Chrome 45.

I just upgraded to Chrome 59 on RedHat 7.0 and it appears to work now. (I use it with chromedriver 2.30 and selenium-server-standalone-3.4.0.ja). I need to do more testing but it's looking hopeful.

Correction to my previous comment (49): This test was on CentOS 7.0, not RedHat 7.0. I'll be testing it on RedHat 7.2 soon though.

arekm@ - Could you please check the issue in latest chrome stable #59.0.3071.115 and please confirm if the issue still exist or not.

Thanks...!!

I'm using 59.* (59.0.3071.115 at this point) and the problem is gone for me.

Thank you for providing more feedback. Adding requester "krajshree@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Closing as per comment #53