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

Issue 14003 link

Starred by 6 users

Issue metadata

Status: Verified
Owner:
ex-Googler
Closed: Mar 2010
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 1
Type: Bug-Regression
M-5

Restricted
  • Only users with EditIssue permission may comment.



Sign in to add a comment

Dock menu crashes when selecting a closed window.

Project Member Reported by sh...@chromium.org, Jun 12 2009

Issue description

What steps will reproduce the problem?
1. Drop the attached file in /tmp or something.
2. Load it.  It will popup a window, wait five seconds, and close it.
3. While loading, right-click the Chrome icon.
4. After close, select the Untitled window.
5. Crash!

I would expect to have the dock menu updated, but that may be excessive.  At least we shouldn't 
crash.

Replicated in v3.0.189 on Mac.
 
test.html
107 bytes View Download

Comment 1 by sh...@chromium.org, Jun 16 2009

Works for Safari, too!  [Need to disable popup-blocking from Safari menu, of course.]
This crash was not found in 3.0.189.0. We last saw it in 3.0.187.0.  Assuming the crash has been fixed, please mark accordingly.

Comment 3 by jon@chromium.org, Jul 14 2009

Labels: Report-to-Webkit Mstone-4
Status: Available
Should be upstreamed to WebKit

Comment 4 by sh...@chromium.org, Jul 14 2009

Labels: -Report-to-Webkit
Is not a webkit problem, it's an OS mal-feature.  Apps register a right-click dock menu which contains 
references to windows, if the window is closed while the dock menu is open, a message goes to an invalid 
object.  I seem to recall that I couldn't replicate it in Snow Leopard.  We could fix for Leopard by having our own 
right-click dock menu and dispatching in a different way.  I had prototyped a fix, but lost the thread when I was 
off tracking more frequent crashers.
Can we have someone in QA check if this crash still exists? Thanks

Comment 6 by finnur@chromium.org, Aug 24 2009

Status: Assigned
I believe the intent was to assign this to a QA person...

Comment 7 by sh...@chromium.org, Aug 25 2009

I can verify this.  As I mentioned, it also happens in Safari, but Snow Leopard fixes it.  It's not horrible to fix if we 
decide to.

Comment 8 by sh...@chromium.org, Aug 25 2009

[#7: I verified it just now with a trunk build of Chromium and OSX 10.5.8 Build 9L31a.]
Chromium version: 4.0.203.0 SVN Revision: 24101
This crash is reproducible with Leopard and SL both.

Comment 11 by jon@chromium.org, Sep 2 2009

Labels: -mstone-4 mstone-5
Not a blocker for mstone-4 moving to mstone-5

Comment 12 by mark@chromium.org, Sep 14 2009

In this corner, Scott says it's fixed in Snow Leopard, but in this corner, rohitbm 
disagrees.  Let's get ready to rumble?

Comment 13 by mark@chromium.org, Sep 14 2009

Comment 14 by sh...@chromium.org, Sep 14 2009

It may be that I could not replicate it for Safari on Snow Leopard, since I think I was playing with Snow Leopard 
@WWDC.

Comment 15 by krisr@chromium.org, Sep 23 2009

I can still reproduce this with:

Platform:
  Hostname: macintosh-0023df98cd1c.local
  Mac OS X Version 10.6.1 (Build 10B504)
  Processor: 2 Intel 2.00 GHz
  RAM: 1024 MB

Chromium:
  Chromium version: 4.0.212.0 SVN Revision: 26685  Release
  QuickTime Player: <unknown>
  QuickTime PlayerX: 51
  Flash Player: 10.0.32

Comment 16 by sh...@chromium.org, Sep 23 2009

I believe I have leverage to fix this now, but it's mstone-5, so...

Comment 17 by krisr@chromium.org, Sep 29 2009

Labels: Crash-Reproducible
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=27769 

------------------------------------------------------------------------
r27769 | shess@chromium.org | 2009-10-01 14:31:18 -0700 (Thu, 01 Oct 2009) | 12 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/chrome_application_mac.mm?r1=27769&r2=27768

[Mac] Don't crash when selecting closed window from Dock menu.

The Dock menu contains an automagic section where you can select
amongst open windows.  This is wired up to send to the window as a
target, but if JavaScript closes the window in the meanwhile, it
messages a freed object.  This short-circuits the specific selector if
the window is no longer valid.

 http://crbug.com/14003 
TEST=Bug contains instructions and an example html file to help.

Review URL: http://codereview.chromium.org/259001
------------------------------------------------------------------------

Status: Fixed
Project Member

Comment 20 by crashbot@chromium.org, Oct 5 2009

Labels: -Pri-2 Pri-1 Crash-4.0.220.1
This crash was found in 4.0.220.1 and is currently ranked #1 (based on the relative number of reports in the release).  There have been 391 reports from 378 clients.

Report Link: http://crash/reportdetail?reportid=d5767a2dadc6574e
http://crash/search?query=Chrome+4.0.220.1+base%3A%3AMessagePumpNSApplication%3A%3ADoRun%28base%3A%3AMessagePump%3A%3ADelegate*%29
This crash looks like it has re-appeared in 4.0.220.1
This crash report doesn't look at all related to this bug.  I'm sure I've marked past crash dumps with the bug 
number, but cannot figure out how to search by bug number so I can't offer an example.  There was a line with 
Dock* in it, though.
Status: Verified
Platform:
  Hostname: Macintosh-0017f2d64524.local
  Mac OS X Version 10.5.8 (Build 9L27)
  Processor: 2 Intel 2.33 GHz
  RAM: 2048 MB

Chrome:
  Chrome version: 4.0.221.6  <<<Release>>>
  QuickTime Player: 7.6.4
  QuickTime PlayerX: <unknown>
  Flash Player: 10.0.32

Project Member

Comment 23 by crashbot@chromium.org, Oct 8 2009

Labels: Crash-4.0.221.8
This crash was found in 4.0.221.8 and is currently ranked #4 (based on the relative number of reports in the release).  There have been 71 reports from 70 clients.

Report Link: http://crash/reportdetail?reportid=4a2e0f9951d4e7bc
http://crash/search?query=Chrome+4.0.221.8+base%3A%3AMessagePumpNSApplication%3A%3ADoRun%28base%3A%3AMessagePump%3A%3ADelegate*%29
This crash looks like it has re-appeared in 4.0.221.8

Comment 24 by sh...@chromium.org, Oct 18 2009

I'm seeing some more crashes which seem like the backtraces I was seeing for this
one.  I do not know why.  Specifically, things like:

DockCallback(unsigned long, unsigned int, void*, void*)
_DCXSelectWindow
_XSelectWindow

maybe there's something additional going on?

Comment 25 by sh...@chromium.org, Oct 18 2009

Status: Assigned
Labels: Regression
So ... I continue to see these crashers.  The original repro was fixed, but obviously
there's some other means of provoking DockCallback() without ending up in
-sendaction:to:from:.  Probably will require some detective work to figure out which
messages DockCallback can send.

Comment 27 by ben@chromium.org, Nov 18 2009

Labels: -Size-Medium -mstone-5 Mstone-5

Comment 28 by oritm@chromium.org, Dec 18 2009

Labels: -Area-BrowserUI Area-UI-Features
Updating labels:
Area-UI-Features replaces Area-BrowserUI

Labels: -Area-UI-Features Area-Feature
Labels: BetaCandidate
Labels: -BetaCandidate
Labels: ReleaseBlock-Stable
I spent some time today looking into this.

There are some other cases where DockCallback() is called.  AFAICT, it is called in constructing the menu 
originally, and then in sending messages from the menu.  It appears to be invoked under the covers to handle a 
mach message, I haven't been able to find a place where you can hook it.

I have not been able to construct an alternate attack based on this knowledge - I've managed some weird cases 
in app shutdown, but none which look like what's on the crash server (and they don't crash, so I think they're a 
red herring).  One suspicion I have is that there's a cross-over between objects being freed and the initial dock-
menu setup, so that somehow a freed object is asked to validate or something.  Maybe -targetForAction:to:from: 
could be hooked like -sendAction:to:from: is already hooked?  Do not know, since I don't have a repro case.

BTW, this crash has been SUBSTANTIALLY reduced from 4.0.249.*.  307.5 has no hits at all.  307.1 had two, 
neither as generic as this buy used to be (they get far into actual Cocoa code).  302.2 has it happening in the 
plugin process, which is just weird (and one browser crash from 34110).  295.0 had one in an oom.  288.1 had 
one which was actually 34110.  So maybe this bug has been fixed by something else?

[If so, it's not an OS update - 249.49 is still crashing in this today.]
Labels: -Area-Feature Area-UI
Labels: -ReleaseBlock-Stable ReleaseBlock-NextBeta
Labels: -ReleaseBlock-NextBeta ReleaseBlock-Beta

Comment 37 by sh...@chromium.org, Mar 24 2010

Status: Fixed
I can only find one 307.11 crash for this (there are others with DockCallback() on the stack, but they are other 
bugs).  AFAICT we've not fixed anything, but since it doesn't seem to be happening any longer (and the original 
primary problem was fixed), I'm marking it fixed.
Status: Verified
On Leopard and Snow Leopard
Google Chrome	5.0.365.0 (Official Build 43016) unknown
WebKit	533.3
V8	2.2.0
Labels: -Regression bulkmove Type-Regression
What steps will reproduce the problem?
1. Drop the attached file in /tmp or something.
2. Load it.  It will popup a window, wait five seconds, and close it.
3. While loading, right-click the Chrome icon.
4. After close, select the Untitled window.
5. Crash!

I would expect to have the dock menu updated, but that may be excessive.  At least we shouldn't 
crash.

Replicated in v3.0.189 on Mac.
Project Member

Comment 40 by bugdroid1@chromium.org, Oct 13 2012

Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Project Member

Comment 41 by bugdroid1@chromium.org, Mar 10 2013

Labels: -Mstone-5 -Area-UI -Type-Regression Type-Bug-Regression M-5 Cr-UI
Project Member

Comment 42 by bugdroid1@chromium.org, Mar 13 2013

Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue

Sign in to add a comment