| Issue 265932 | Crash + logout of entire Mac session related to Hangouts extension (perhaps GPU related?) | ||||||||||||||||||||||||||||||
| Starred by 27 users | Project Member Reported by creis@chromium.org, Jul 30 2013 | Back to list | |||||||||||||||||||||||||||||
Sign in to add a comment
|
Version: 28.0.1500.71 OS: OS X 10.8.4 What steps will reproduce the problem? 1. Install the Hangouts extension from https://chrome.google.com/webstore/detail/hangouts/ljclpkphhpbpinifbeabbhlfddcpfdde 2. Receive a chat from someone. 3. Minimize the chat window and watch it animate away at the bottom of the screen. As the animation is in progress, the entire Mac desktop session crashes, and I get logged out. There's no crash report in chrome://crashes. These steps aren't 100% reproducible and it may be possible to see this crash without minimizing a chat window. (Nasko suspects it may be a GPU issue that the Hangouts extension is triggering?) However, I can confirm that I haven't seen the crash+logout since uninstalling the Hangouts extension two weeks ago, and Nasko just saw the issue multiple times today with the Hangouts extension installed (once by minimizing the chat, once not). This seems pretty severe, given that it logs you out of your entire Mac session.
Comment 1
by
creis@chromium.org,
Jul 30 2013
,
Jul 30 2013
Do you have any crash reports from the event in ~/Library/Logs/DiagnosticReports/?
,
Jul 30 2013
No diagnostic reports on my machine.
,
Jul 30 2013
Nasko doesn't have any, and I have two that don't seem related based on the dates.
,
Jul 30 2013
Do you have any from either the WindowServer or loginwindow process? If either of those processes crashed, that would take down the active GUI session. You may also check /Library/Logs/DiagnosticReports.
,
Jul 30 2013
Attaching the crash reports found in the global /Library/Logs/DiagnosticReports.
,
Jul 30 2013
Two of those three crashes have this stack: Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 com.apple.CoreGraphics 0x00007fff8704f754 CGBlt_copyBytes + 692 1 com.apple.CoreGraphics 0x00007fff872c0f34 window_shadow_get_return + 1036 2 com.apple.CoreGraphics 0x00007fff872c32fc CGXWindowShadowGet + 8180 3 com.apple.CoreGraphics 0x00007fff8709225e insertWindowShadowLayers + 2743 4 com.apple.CoreGraphics 0x00007fff87090ae4 redraw_window + 9535 5 com.apple.CoreGraphics 0x00007fff87089a1a CGXUpdateDisplay + 6059 6 com.apple.CoreGraphics 0x00007fff871c573f run_timer_pass + 381 7 com.apple.CoreGraphics 0x00007fff87097f62 CGXRunOneServicesPass + 198 8 com.apple.CoreGraphics 0x00007fff87098722 CGXServer + 1000 9 WindowServer 0x0000000103211f41 main + 9 10 libdyld.dylib 0x00007fff909ee7e1 start + 1 I wonder if this is because of the weird things we have to do with both panels and browser windows to get the window shadow right.
,
Jul 30 2013
For reference, I have 3 WindowServer crash report files with that stack as well. Nice find.
,
Jul 30 2013
There's also reports on the wider internet of this happening if you Google the functions in that stack. Unfortunately, we don't know some important things:
1. Steps to reproduce
2. Whether this was precepitated by a change in:
a. Chrome
b. The Hangouts plugin ("ace.bundle")
c. The Hangouts JS code
,
Jul 30 2013
I see reports here as well: http://productforums.google.com/forum/#!category-topic/hangouts/pSnfQMOA-E8 This seemed to start getting reported recently. There have been no recent changes in the ace.bundle. The last change was about 5/15. There have likely been changes in the talk plugin (the plugin used for video Hangouts) which is started by the extension. There are weekly changes in the js code for the extension but nothing dramatic lately. Minimizing windows seems to be consistent in the repro steps.
,
Jul 30 2013
Could anyone try to disable GPU compositing via chrome://flags and check if this could still be reproduced?
,
Jul 31 2013
,
Jul 31 2013
I've tried disabling compositing and still seeing this issue regularly, as are a handful of my friends in an OSX office. Most are running 10.8.4.
,
Jul 31 2013
At first I thought this coincided with the release of 28.0.1500.95, but the first report in this chain listed version 28.0.1500.71 which was released July 9. It is odd that there was this sudden rise in reports of this just recently (when there were no apparent Chrome changes, no ace.bundle changes, minimal Hangouts js extension code changes).
,
Jul 31 2013
m28 is the first release to enable force compositing mode on mac, maybe that's related?
,
Jul 31 2013
If all the reports are from 10.8 it is possible that it's related to FCM. We haven't yet enabled FCM on 10.6 or 10.7..
,
Jul 31 2013
All reports that I see mention 10.8.4. david7902 mentioned most are running 10.8.4 but it was unclear if this happened on any machine not on 10.8.4
,
Aug 1 2013
I am experiencing this exact same issue. I noticed it when the most recent OS update got pushed out to my 2012 MBA. Almost immediately after rebooting. My crash log: Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 com.apple.CoreGraphics 0x000000010e00f754 CGBlt_copyBytes + 692 1 com.apple.CoreGraphics 0x000000010e280f34 window_shadow_get_return + 1036 2 com.apple.CoreGraphics 0x000000010e2832fc CGXWindowShadowGet + 8180 3 com.apple.CoreGraphics 0x000000010e05225e insertWindowShadowLayers + 2743 4 com.apple.CoreGraphics 0x000000010e050ae4 redraw_window + 9535 5 com.apple.CoreGraphics 0x000000010e049a1a CGXUpdateDisplay + 6059 6 com.apple.CoreGraphics 0x000000010e18573f run_timer_pass + 381 7 com.apple.CoreGraphics 0x000000010e057f62 CGXRunOneServicesPass + 198 8 com.apple.CoreGraphics 0x000000010e058722 CGXServer + 1000 9 WindowServer 0x000000010db67f41 main + 9 10 libdyld.dylib 0x000000010f8897e1 start + 1
,
Aug 1 2013
I'm getting this on 10.8.4 as well
,
Aug 1 2013
I have some crash reports, all with the same thread crash log, I've already posted them here https://code.google.com/p/chromium/issues/detail?id=134286
,
Aug 1 2013
I confirmed that all 4 of us were running 10.8.4 at the time of the crashes. Between us we have a dozen or so crashes/logouts of the same flavor as the ones posted. All seem to have occurred after the Security Update 2013-003. We have not seen it happen under 10.9, and some are using that more extensively - same hangout usage / same groups of contacts.
,
Aug 1 2013
I'm getting this on 10.8.4, today was 5 crashes
,
Aug 1 2013
This discussion: https://discussions.apple.com/thread/5166450 indicates that the problem is probably not limited to Chrome+Hangouts, some people get crashes using other apps.
,
Aug 2 2013
That may be, but I can confirm that disabling the Hangout Plugin eliminates all such crashes that I've been seeing...
,
Aug 2 2013
This has been happening to several users I've been speaking to in the last day. Just happened to me for the first time... lost a bit of work for my trouble. Then hangouts app on Mac has already had a bad reputation (takes up 100% CPU even when no video or audio is streaming etc.) I really hope they fix this, until then I'm removing the plugin.
,
Aug 2 2013
So far this has happened on a 13" MBP (2009) and a 15" MBP (2012) both running the latest version of Chrome and the Hangouts extension on 10.8.4. Interestingly, this hasn't happened on my MacPro, also running the latest version of Chrome + Hangouts, and 10.8.4. Someone suggested in a forum that Hangouts was the cause. I removed it for several days and no more crashing on the MPBs. Reinstalled the Hangouts extension and a day later WindowServer crashed.
,
Aug 2 2013
More clues: I re-enabled the Hangouts plugin yesterday with these options turned off: - Keep Hangouts on top of other windows - Show system tray icon I've been running and using hangouts extensively for almost 24 hours without a crash (previously getting about 4-5 a day). Also FWIW, I'm using a 17inch Early 2011 MBP.
,
Aug 2 2013
david7902: That's interesting. Based on the crash stack in WindowServer, I'm inclined to think that "Keep Hangouts on top of other windows" is the problem, since the stack mentions calculating window shadows. Could you try reenabling "Show system tray icon" while keeping the other option off?
,
Aug 2 2013
Yes, I would be included to think the same and only turned off both because one of my crashes was right when I was clicking on the menu bar helper / system tray icon. However, as requested I've enabled that option and been running that way the last couple of hours without a hitch. I will continue to test with this setup.
,
Aug 2 2013
david7902, could you please remember what was the last thing you did when you hit a crash? Have you tried to minimize any of the hangout windows right before the crash?
,
Aug 2 2013
,
Aug 2 2013
I've had quite a variety: Most of the time, I have minimized 3-5 hangout windows on the bottom right side of my main (center of 3) display and was not interacting with them at the time of a crash / logout. I was interacting in a Chrome browser window or XCode. At least a couple of times, I had just focused one of the hangout window input fields and was about to type a message. One time, as stated above, I was clicking on the menu bar helper / system tray icon. Based on the typical chat activity, it's likely/possible I was receiving a message or hangout rename notification at or just before some or maybe all of the crashes.
,
Aug 2 2013
Importantly, in answer to your question, I had not recently (within a few seconds) minimized in any case I can recall. However usually all but one or two of the windows was in a minimized state.
,
Aug 3 2013
I've been running hangouts without the "Keep Hangouts on top of other windows" option enabled and seems to not be logging out my session anymore. So I think that option has definitely something to do with it.
,
Aug 3 2013
I've also disabled "Keep Hangout's on top of other windows" and had haven't had any crashes so far.
,
Aug 5 2013
I am also experiencing the WM crash while having the hangouts extension installed on a up-to-date system. Out of three crashes so far, two contain the above mentioned stack trace ending with CGBlt_copyBytes but one contains the following stack: Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 com.apple.QuartzCore 0x00007fff93ebda7f x_mem_alloc_size + 106 1 com.apple.QuartzCore 0x00007fff93ebcaaf CA::ShapeHandle::finish(int const*) + 657 2 com.apple.QuartzCore 0x00007fff93edab6a CA::Shape::Union(CA::Shape const*) const + 350 3 com.apple.QuartzCore 0x00007fff93edaa03 CA::Shape::Union(CA::Bounds const&) const + 75 4 com.apple.QuartzCore 0x00007fff93eca91f CA::shape_union(CA::Shape**, CA::Bounds const&) + 57 5 com.apple.QuartzCore 0x00007fff93eca8a4 CA::Render::Context::invalidate(CA::Bounds const&) + 50 6 com.apple.QuartzCore 0x00007fff93ed9547 CA::Render::Updater::prepare_layer(CA::Render::Updater::GlobalState&, CA::Render::Updater::LocalState&, CA::Render::LayerNode*, CA::Render::Updater::LayerShapes&, unsigned int*) + 6653 7 com.apple.QuartzCore 0x00007fff93ed95c4 CA::Render::Updater::prepare_layer(CA::Render::Updater::GlobalState&, CA::Render::Updater::LocalState&, CA::Render::LayerNode*, CA::Render::Updater::LayerShapes&, unsigned int*) + 6778 8 com.apple.QuartzCore 0x00007fff93ed606c CA::Render::Update::add_context(CA::Render::Context*, CA::Render::Layer*, CA::Transform const*) + 1240 9 com.apple.CoreGraphics 0x00007fff89c3fc77 CGXBeginSurfaceLayerUpdate + 699 10 com.apple.CoreGraphics 0x00007fff89bd5109 prepare_CoreAnimation_update_state + 330 11 com.apple.CoreGraphics 0x00007fff89bcf5d4 CGXUpdateDisplay + 869 12 com.apple.CoreGraphics 0x00007fff89d0c73f run_timer_pass + 381 13 com.apple.CoreGraphics 0x00007fff89bdef62 CGXRunOneServicesPass + 198 14 com.apple.CoreGraphics 0x00007fff89bdf722 CGXServer + 1000 15 WindowServer 0x0000000100168f41 main + 9 16 libdyld.dylib 0x00007fff91e107e1 start + 1
,
Aug 5 2013
Before we can assign this bug, we need a reliable repro scenarios. JianLi has been unable to repro the bug on his system. Things that might help: Finding out what the user was doing right before the crash or a list of windows open.
,
Aug 6 2013
I was just able to reproduce the problem. While it doesn't happen every time I was able to get it to happen within about 5 min. I think it has to do with the "Keep Hangouts on top of other windows" option. 1. Have the Hangout Windows with all of your chats open. 2. Have Chrome open in the background with the page in focus but hangouts on top of Chrome. 3. Minimize Hangouts while Chrome is still in focus. I was also tabbing back and forth using command ~ to see if that made a difference. G+ was the active Chrome tab but I also had reddit.com, slashdot.org, zdnet.com, and support.apple.com in other tabs. Crash report below: Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 com.apple.CoreGraphics 0x0000000108b52ed5 magazine_alloc + 56 1 com.apple.CoreGraphics 0x0000000108b5ab70 x_realloc + 33 2 com.apple.CoreGraphics 0x0000000108b593ee size_check + 85 3 com.apple.CoreGraphics 0x0000000108b5b579 shape_intersect + 546 4 com.apple.CoreGraphics 0x0000000108ed4caa _CGXGLPrepareLayers + 473 5 com.apple.CoreGraphics 0x0000000108ed441b CGXGLAccelComposite + 854 6 com.apple.CoreGraphics 0x0000000108e07b61 CGLayerComposite + 137 7 com.apple.CoreGraphics 0x0000000108bfdd90 CGXUpdateDisplay + 6945 8 com.apple.CoreGraphics 0x0000000108d3973f run_timer_pass + 381 9 com.apple.CoreGraphics 0x0000000108c0bf62 CGXRunOneServicesPass + 198 10 com.apple.CoreGraphics 0x0000000108c0c722 CGXServer + 1000 11 WindowServer 0x0000000108717f41 main + 9 12 libdyld.dylib 0x000000010a42f7e1 start + 1
,
Aug 8 2013
Here is my crash log. I minimized my hangouts window then wend back to a chrome window then back to hangouts and my cursor disappeared then I logged out. This happens 2-3 times a day.
,
Aug 8 2013
Thank you very much for all your reports. For those who can repro this crash plus logout, could you please help try the latest Mac Canary build (with special command line option) to see if you still repro the crash? You can install the Mac Canary build from https://www.google.com/intl/en/chrome/browser/canary.html. The Canary build will live side-by-side with your stable/beta build. If you already run the Canary build, please make sure it is updated to the version not lower than 30.0.1590.2. Please launch your Canary build from your Terminal via the following command: open /Applications/Google\ Chrome\ Canary.app --args --enable-panel-experiment Please note that you will see a small white strip overlapping the bottom part of the minimized window when you minimize a hangout window. This does not affect any of Hangout experience.
,
Aug 9 2013
Whole day with canary using those args and it worked fine, tried to minimize it many times and no crashes so far!
,
Aug 9 2013
I turned off "Keep on top", then clicked the Canary link in comment #40 and BOOM!. Logged out.
,
Aug 11 2013
Couple of days now using Canary with "Keep Hangouts on top of other windows" enabled and "Show system tray icon" disabled and no logouts so far.
,
Aug 13 2013
------------------------------------------------------------------------ r217139 | jianli@chromium.org | 2013-08-13T00:49:03.926797Z Changed paths: M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/ui/cocoa/panels/panel_window_controller_cocoa.mm?r1=217139&r2=217138&pathrev=217139 [Mac] Change to detach the web contents view when the panel is not taller than the titlebar. We used to hide the web contents view in such case but it seems to trigger some bad effect occasionally. BUG= 265932 TEST=existing tests R=ccameron@chromium.org, dimich@chromium.org Review URL: https://codereview.chromium.org/22629009 ------------------------------------------------------------------------
,
Aug 13 2013
I have been having this happen to me randomly for a few months maybe 2. There is also another person in my office experiencing the same issues. I have not been able to recreate a process to get the logout to happen. Most recently I was working with images in Adobe PS. I had 3 hangout windows open including the main tray. 2 were minimized at the bottom of the screen and one was popped up. I am rather sure that I received a message in the open hangout clicked on it so it would no longer be green then clicked back into PS. Bam logout. I found this thread and have now updated my preferences to not Keep Hangouts on top of other windows. So far so good. However, this bug has not been happening to me very often.
,
Aug 13 2013
Oh, myself and my co-worker above are both running OSX 10.8.4 with the most recent releases of Chrome and Hangouts.
,
Aug 13 2013
The fix is landed in the latest Mac canary build (30.0.1599.0). Could anyone who runs the Canary build verify it?
,
Aug 13 2013
Approved pending verification for merge.
,
Aug 13 2013
,
Aug 13 2013
I've been using it on today's canary and it hasn't crashed yet. Looks good so far.
,
Aug 13 2013
------------------------------------------------------------------------ r217371 | jianli@chromium.org | 2013-08-13T23:06:02.204443Z Changed paths: M http://src.chromium.org/viewvc/chrome/branches/1547/src/chrome/browser/ui/cocoa/panels/panel_window_controller_cocoa.mm?r1=217371&r2=217370&pathrev=217371 Merge 217139 "[Mac] Change to detach the web contents view when ..." > [Mac] Change to detach the web contents view when the panel is not taller than the titlebar. > > We used to hide the web contents view in such case but it seems to trigger some bad effect occasionally. > > BUG= 265932 > TEST=existing tests > R=ccameron@chromium.org, dimich@chromium.org > > Review URL: https://codereview.chromium.org/22629009 TBR=jianli@chromium.org Review URL: https://codereview.chromium.org/23139002 ------------------------------------------------------------------------
,
Jun 18 2014
|
||||||||||||||||||||||||||||||
| ► Sign in to add a comment | |||||||||||||||||||||||||||||||