(No comment was entered for this change.)

4.0.302.3 (Official Build 36935) dev

Since this bug has repro steps, marking others as dup of this problem.

Thread 0 (crashed)
 0 libobjc.A.dylib     0.227.0.0            0x92a62684 objc_msgSend + 0x14
 1 Google Chrome Framew0.302.3.0            0x029d8fb1 RenderWidgetHost::OnMsgShowPopup(ViewHostMsg_ShowPopup_Params const&) + 0x46 (render_widget_host.cc:854)
 2 Google Chrome Framew0.302.3.0            0x029dc539 RenderWidgetHost::OnMessageReceived(IPC::Message const&) + 0x25 (tuple.h:422)
 3 Google Chrome Framew0.302.3.0            0x029b3dd2 BrowserRenderProcessHost::OnMessageReceived(IPC::Message const&) + 0x10 (browser_render_process_host.cc:776)
 4 Google Chrome Framew0.302.3.0            0x030a3dda RunnableMethod<IPC::ChannelProxy::Context, void (IPC::ChannelProxy::Context::*)(IPC::Message const&), Tuple1<IPC::Message> 
>::Run() + 0x13 (tuple.h:422)
 5 Google Chrome Framew0.302.3.0            0x02bbb55a MessageLoop::DeferOrRunPendingTask(MessageLoop::PendingTask const&) + 0x7 (message_loop.cc:320)
 6 Google Chrome Framew0.302.3.0            0x02bbbeaa MessageLoop::DoWork() + 0xb (message_loop.cc:435)
 7 Google Chrome Framew0.302.3.0            0x02b97b73 base::MessagePumpCFRunLoopBase::RunWorkSource(void*) + 0xa (message_pump_mac.mm:291)
 8 CoreFoundation      0.476.19.0           0x901453c4 CFRunLoopRunSpecific + 0xc44
 9 CoreFoundation      0.476.19.0           0x90145aa7 CFRunLoopRunInMode + 0x57
10 HIToolbox           0.353.0.0            0x909a02ab RunCurrentEventLoopInMode + 0x11a
11 HIToolbox           0.353.0.0            0x909a00c4 ReceiveNextEventCommon + 0x175
12 HIToolbox           0.353.0.0            0x9099ff38 BlockUntilNextEventMatchingListInMode + 0x69
13 AppKit              0.949.54.0           0x9624f6d4 _DPSNextEvent + 0x290
14 AppKit              0.949.54.0           0x9624ef87 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 0x7f
15 AppKit              0.949.54.0           0x96247f9e -[NSApplication run] + 0x31a
16 Google Chrome Framew0.302.3.0            0x02b9761c base::MessagePumpNSApplication::DoRun(base::MessagePump::Delegate*) + 0x19 (message_pump_mac.mm:677)
17 Google Chrome Framew0.302.3.0            0x02b96da5 base::MessagePumpCFRunLoopBase::Run(base::MessagePump::Delegate*) + 0xb (message_pump_mac.mm:213)
18 Google Chrome Framew0.302.3.0            0x02bbb4a3 MessageLoop::Run() + 0xb (message_loop.cc:205)
19 Google Chrome Framew0.302.3.0            0x0273ece2 BrowserMain(MainFunctionParams const&) + 0x7 (browser_main.cc:163)
20 Google Chrome Framew0.302.3.0            0x0265557a ChromeMain + 0xd (chrome_dll_main.cc:748)
21 Google Chrome                            0x00001fc5 
22 

crash_report.txt 17.0 KB   View   Download

 Issue 31856  has been merged into this issue.

(No comment was entered for this change.)

(No comment was entered for this change.)

seems bad, adding some keys before triage.

There's a missing stack frame between 0 and 1:
    RenderWidgetHostViewMac::ShowPopupWithItems
It's unfortunate that there's no line number for it. :(

that's exactly the stack frame that shess is tracking down in 31716.

you two can work it out as to who wants to fix it and if you want to mark this bug a 
duplicate of that bug.

Yup, looks like a dup. This bug has some nice simple steps to reproduce, though, which 
might help. (Haven't tried yet myself.)

I'll go through and verify, but I suspect that the fix will be enough different from the fix for 31716 that I'll 
probably unmark it as dup.

To clarify: The bad state you end up in is the same because the eventual target has been freed (or whatever) but 
the mechanism by which it is freed is probably unrelated.

OK, I've pulled the status back to Started and I'll work on it. I can easily reproduce the 
crash.

(No comment was entered for this change.)

In gdb I get a few more stack frames:
#0  0x97413684 in objc_msgSend ()
#1  0x0775e1f4 in WebKit::WebInputEventFactory::mouseEvent (event=0x2bc6ca0, view=0x6f7a616d) at 
/Volumes/Chromium/src/third_party/WebKit/WebKit/chromium/src/mac/WebInputEventFactory.mm:1026
#2  0x06c52eb3 in RenderWidgetHostViewMac::ShowPopupWithItems (this=0x1b375fb0, bounds=@0xbfffc5f0, 
item_height=13, selected_item=0, items=@0xbfffc684) at 
/Volumes/Chromium/src/chrome/browser/renderer_host/render_widget_host_view_mac.mm:429
#3  0x06c428db in RenderWidgetHost::OnMsgShowPopup (this=0x2bae850, params=@0xbfffc66c) at 
/Volumes/Chromium/src/chrome/browser/renderer_host/render_widget_host.cc:854
...

The RenderWidgetHost (receiver in my frame #3 and #6) has already been deleted.

RenderWidgetHostViewMac::ShowPopupWithItems is running until the popup is 
canceled. By the time it exits its [menu_runner runMenuInView:...] call, its parent 
RenderWidgetHost has been deleted.

Looks like before the host is deleted it needs to make its view cancel the pop-up 
somehow.

Actually the RenderWidgetHostViewMac has _also_ been deleted by this time ... while its 
ShowPopupWithItems call was handling the pop-up. (I didn't notice earlier because its 
memory got overwritten by another object, not garbage.)
So somehow we have to defer the deletion of the RWHVM while its pop-up is showing. 
It's the cocoa_view_'s dealloc method that causes deletion, so retaining the cocoa_view 
while running the pop-up ought to do it.

Hmm.  Just retaining the RWHVM just lets the first level of message be sent, but what if RWHVM wants to 
message someone else who is deleted?  At some point you really just want to make sure that the menu becomes 
inert.  In the first pass of fixing this class of problem last fall, I prototyped a wrapper which caught these cases 
and redirected the NSMenu targets to nil when the thing happened (tab close or whatever).

Actually, that's overkill.  How about restructuring ShowPopupWithItems() so that the last section is called via a 
task from a ScopedRunnableMethodFactory.  Then if the RWHVM disappears in the meanwhile, the results from 
the popup just evaporate.  [Did that make sense?  It makes sense in my head.]

(No comment was entered for this change.)

I was 99% certain that I saw this merged over to 307.2.  But:
   http://crash/reportdetail?reportid=60f3742e78c1eed5
argues otherwise?

Yes, I merged it into 307 — here's the code review page drover created:
http://codereview.chromium.org/548191/show

Is "307.2" a different branch? I've been using "307" as the branch name to merge to.

Looks like 307.1 is the thing on the channel, and it was cut at 37331 (your merge went in at 37440).

Am bummed out.

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=37438 

------------------------------------------------------------------------
r37438 | snej@chromium.org | 2010-01-28 13:24:12 -0800 (Thu, 28 Jan 2010) | 6 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/renderer_host/render_widget_host_view_mac.mm?r1=37438&r2=37437

Fix Mac crash when page goes away while a pop-up menu is active.
This may also fix the older related  bug 31716 .
BUG=33250
TEST=see steps to reproduce in the bug report

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

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=37440 

------------------------------------------------------------------------
r37440 | snej@chromium.org | 2010-01-28 13:30:32 -0800 (Thu, 28 Jan 2010) | 9 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/branches/307/src/chrome/browser/renderer_host/render_widget_host_view_mac.mm?r1=37440&r2=37439

Merge 37438 - Fix Mac crash when page goes away while a popup menu is active.
This may also fix some cases of the older related  bug 31716 .
BUG=33250
TEST=see steps to reproduce in the bug report

Review URL: http://codereview.chromium.org/558021

TBR=snej@chromium.org
Review URL: http://codereview.chromium.org/548191
------------------------------------------------------------------------

Chrome version: 5.0.307.5 r37950

 Issue 35384  has been merged into this issue.

removing formerge label from verified bugs.

Chrome Version       : 4.0.302.2 (Official Build 36665) dev (Mac)
<b>URLs (if applicable) :</b>
<b>Other browsers tested:</b>
<b>Add OK or FAIL after other browsers where you have tested this issue:</b>
     Safari 4: OK
<b>Firefox 3.x:</b>
<b>IE 7:</b>
<b>IE 8:</b>

<b>What steps will reproduce the problem?</b>
1. Go to amazon.com
2. Submit the search form at the top.
3. Before the next page loads, click on the drop-down to the left to open 
it.
4. Once the next page loads, click on the page to close the drop-down.

<b>What is the expected result?</b>
The drop down closes.

<b>What happens instead?</b>
The browser crashes

<b>Please provide any additional information below. Attach a screenshot if</b>
<b>possible.</b>
Experienced this on on Mac OS X 10.6.2