CL out for review: http://codereview.chromium.org/3158031

I patched in the new CL and was able to trigger the crash with roughly the following steps:

1. Launch Chrome
2. Show Bookmark Bar
3. Create top-level folder
4. Fill with random links
5. Create sub-folder and fill it with random links
6. Mouse around a bit
7. Cmd-W, Cmd-W, Cmd-W... quickly until all windows are gone

Then crash.

Note, I've only repro'd once, but triggers with no windows still open and the code thinks it is still inside the button (ie. no mouse-exited from the cell).

Here's the stack

#0	0x003a5a7d in (anonymous namespace)::ZombieObjectCrash at objc_zombie.mm:211
#1	0x003a5b73 in -[CrZombie forwardingTargetForSelector:] at objc_zombie.mm:249
#2	0x90cb8416 in __NSGetForwardingTarget
#3	0x90cb8390 in __forwarding_prep_0___
#4	0x003079af in -[BookmarkButton mouseExited:] at bookmark_button.mm:152
#5	0x0030818a in -[BookmarkButton dealloc] at bookmark_button.mm:52
#6	0x90c4ac68 in CFRelease
#7	0x90c7791d in _CFAutoreleasePoolPop
#8	0x98959db6 in NSPopAutoreleasePool
#9	0x90cc16e2 in CFRunLoopTimerInvalidate
#10	0x90c7cabb in __CFRunLoopRun
#11	0x90c7a094 in CFRunLoopRunSpecific
#12	0x90c79ec1 in CFRunLoopRunInMode
#13	0x9945ff9c in RunCurrentEventLoopInMode
#14	0x9945fd51 in ReceiveNextEventCommon
#15	0x9945fbd6 in BlockUntilNextEventMatchingListInMode
#16	0x973a7a89 in _DPSNextEvent
#17	0x973a72ca in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:]
#18	0x9736955b in -[NSApplication run]
#19	0x00c1a454 in base::MessagePumpNSApplication::DoRun at message_pump_mac.mm:677
#20	0x00c1aa43 in base::MessagePumpCFRunLoopBase::Run at message_pump_mac.mm:213
#21	0x00bb9db8 in MessageLoop::RunInternal at message_loop.cc:256
#22	0x00bb9dd3 in MessageLoop::RunHandler at message_loop.cc:228
#23	0x00bb9e37 in MessageLoop::Run at message_loop.cc:206
#24	0x00265845 in (anonymous namespace)::RunUIMessageLoop at browser_main.cc:488
#25	0x002684b1 in BrowserMain at browser_main.cc:1445
#26	0x00008aa4 in ChromeMain at chrome_dll_main.cc:920
#27	0x00001f52 in main at chrome_exe_main.mm:16

I've also attached a "full" backtrace from GDB so you can see variable state as well.

bt.txt 22.2 KB   View   Download

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

------------------------------------------------------------------------
r57399 | jrg@chromium.org | 2010-08-25 14:49:44 -0700 (Wed, 25 Aug 2010) | 7 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/cocoa/bookmark_bar_controller.mm?r1=57399&r2=57398
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/cocoa/bookmark_bar_folder_controller.mm?r1=57399&r2=57398
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/cocoa/bookmark_button_cell.mm?r1=57399&r2=57398

Try to fix top crasher.

The problem is timing related so I am unable to write a unit test which proves this fixes things.  The essence of the change is to make sure we don't send messages to objects which no longer exist by clearing the delegate pointer in objects we own before we go away (where "we" is an object).  The delegate pattern does not get retained, which gives certain objects to hold dangling pointers.  

BUG=53205  http://crbug.com/53205

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

Drovered to 472

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

------------------------------------------------------------------------
r57427 | jrg@chromium.org | 2010-08-25 17:07:00 -0700 (Wed, 25 Aug 2010) | 10 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/branches/472/src/chrome/browser/cocoa/bookmark_bar_controller.mm?r1=57427&r2=57426
   M http://src.chromium.org/viewvc/chrome/branches/472/src/chrome/browser/cocoa/bookmark_bar_folder_controller.mm?r1=57427&r2=57426
   M http://src.chromium.org/viewvc/chrome/branches/472/src/chrome/browser/cocoa/bookmark_button_cell.mm?r1=57427&r2=57426

Merge 57399 - Try to fix top crasher.

The problem is timing related so I am unable to write a unit test which proves this fixes things.  The essence of the change is to make sure we don't send messages to objects which no longer exist by clearing the delegate pointer in objects we own before we go away (where "we" is an object).  The delegate pattern does not get retained, which gives certain objects to hold dangling pointers.  

BUG=53205  http://crbug.com/53205

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

TBR=jrg@chromium.org
Review URL: http://codereview.chromium.org/3150039
------------------------------------------------------------------------

(No comment was entered for this change.)

Verified label updated by AutoAllocator, contact AmolK or KrisR for details

7.0.513.0 (Official Build 58304) dev

Product: Chrome_Mac
Stack Signature: ZombieObjectCrash-6B8C89
New Signature Label: ZombieObjectCrash
New Signature Hash: 57696c0d_bfeeb16b_86ded81e_b8157573_0f85f2f6

Report link: http://go/crash/reportdetail?reportid=94d8ec437f9dc6f4

Meta information:
Product Name: Chrome_Mac
Product Version: 6.0.472.41
Report ID: 94d8ec437f9dc6f4
Report Time: 2010/08/24 12:50:10, Tue
Uptime: 3 sec
Cumulative Uptime: 0 sec
OS Name: Mac OS X
OS Version: 10.6.4 10F569
CPU Architecture: x86
CPU Info: GenuineIntel family 6 model 23 stepping 10

0x00214204	 [Google Chrome Framework	 - objc_zombie.mm:211]	ZombieObjectCrash
0x002142e2	 [Google Chrome Framework	 - objc_zombie.mm:249]	-[CrZombie forwardingTargetForSelector:]
0x90aac415	 [CoreFoundation	 + 0x0007a415]	__NSGetForwardingTarget
0x90aac38f	 [CoreFoundation	 + 0x0007a38f]	__forwarding_prep_0___
0x001adfff	 [Google Chrome Framework	 - bookmark_button.mm:150]	-[BookmarkButton mouseExited:]
0x001ae967	 [Google Chrome Framework	 - bookmark_button_cell.mm:191]	-[BookmarkButtonCell mouseExited:]
0x92e9595d	 [AppKit	 + 0x0007695d]	-[NSApplication sendEvent:]
0x00781fe2	 [Google Chrome Framework	 - chrome_application_mac.mm:43]	-[CrApplication sendEvent:]
0x92e295ba	 [AppKit	 + 0x0000a5ba]	-[NSApplication run]
0x007c303c	 [Google Chrome Framework	 - message_pump_mac.mm:677]	base::MessagePumpNSApplication::DoRun
0x007c27c9	 [Google Chrome Framework	 - message_pump_mac.mm:213]	base::MessagePumpCFRunLoopBase::Run
0x00796f13	 [Google Chrome Framework	 - message_loop.cc:257]	MessageLoop::Run
0x0014b4e3	 [Google Chrome Framework	 - browser_main.cc:372]	BrowserMain
0x0000a451	 [Google Chrome Framework	 - chrome_dll_main.cc:889]	ChromeMain
0x00001f57	 [Google Chrome	 - chrome_exe_main.mm:16]	main
0x00001f15	 [Google Chrome	 + 0x00000f15]	
0x00000001			

NSRangeException reason *** -[NSCFArray objectAtIndex:]: index (24) beyond bounds (24)

One of our top browser crashers on go/crash.

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.

(No comment was entered for this change.)

(No comment was entered for this change.)