161621 - Crash from customizing location field in toolbar with location field present [@ objc_msgSend]

Status: VERIFIED FIXED

(Camino Graveyard :: Toolbars & Menus, defect)

Description

[David Haas (gone, not reading mail)]

Build: 2002080605
Platform: OS X 10.1.5
Expected Results: When customizing toolbar, if location field is already present
in toolbar, dragging a new location field into toolbar, but not dropping it,
then dragging it out & dropping it outside the toolbar should do nothing. 
What I got: Application crashes


Steps to reproduce:

1) Launch Chimera
2) Make sure Location bar is present in toolbar.
3) From the View menu, select Customize Toolbar.
4) Drag a new copy of the Location bar into the toolbar - BUT DO NOT DROP IT IN.
5) Drag the location bar copy back out of the toolbar, then drop it anyplace on
screen besides in the toolbar.
6) Crash occurs.

Here's a crash log:
**********

Date/Time:  2002-08-07 23:40:32 -0500
OS Version: 10.1.5 (Build 5S66)
Host:       rmm010

Command:    Navigator
PID:        5105

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_INVALID_ADDRESS (0x0001) at 0xa67c0c03

Thread 0 Crashed:
 #0   0x706bab68 in objc_msgSend
 #1   0x70162cec in CFRetain
 #2   0x70166b2c in CFArrayReplaceValues
 #3   0x7016691c in CFArrayAppendValue
 #4   0x7081bf54 in -[NSCFArray addObject:]
 #5   0x70eb547c in -[NSToolbarView _itemsFromItemViewers:]
 #6   0x70eb3154 in -[NSToolbarView visibleItems]
 #7   0x70eacc4c in -[NSToolbar visibleItems]
 #8   0x70eaffc0 in -[NSToolbar validateVisibleItems]
 #9   0x70eb733c in -[NSToolbarView _validateVisibleToolbarItems]
 #10  0x708374a8 in _nsNotificationCenterCallBack
 #11  0x7019be68 in _postNotification
 #12  0x701995ec in _CFNotificationCenterPostLocalNotification
 #13  0x70199310 in _CFNotificationCenterPostNotification
 #14  0x7082c2e0 in -[NSNotificationCenter
postNotificationName:object:userInfo:flags:]
 #15  0x70833c14 in -[NSNotificationCenter postNotificationName:object:]
 #16  0x70c4a0e4 in -[NSWindow update]
 #17  0x7081a888 in -[NSArray makeObjectsPerformSelector:withObject:]
 #18  0x70823b18 in -[NSArray makeObjectsPerformSelector:]
 #19  0x70bfe4ac in -[NSApplication(NSWindowCache) _updateWindowsUsingCache]
 #20  0x70c39398 in -[NSApplication updateWindows]
 #21  0x70c306ec in _handleWindowsNeedUpdateNote
 #22  0x7017ba90 in __CFRunLoopDoObservers
 #23  0x7017bdc0 in __CFRunLoopRun
 #24  0x701b70ec in CFRunLoopRunSpecific
 #25  0x7017b8cc in CFRunLoopRunInMode
 #26  0x7312d904 in RunEventLoopInModeUntilEventArrives
 #27  0x731407a4 in ReceiveNextEventCommon
 #28  0x731715fc in BlockUntilNextEventMatchingListInMode
 #29  0x70bd70b8 in _DPSNextEvent
 #30  0x70bfe5d8 in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:]
 #31  0x70c23468 in -[NSApplication run]
 #32  0x70c91ed0 in NSApplicationMain
 #33  0x000044e8 in main
 #34  0x00004398 in _start
 #35  0x000041c8 in start

Thread 1:
 #0   0x700252ec in select
 #1   0x0101d804 in poll
 #2   0x01019ecc in _pr_poll_with_poll
 #3   0x0015e164 in nsSocketTransportService::Run(void)
 #4   0x05058da4 in nsThread::Main(void *)
 #5   0x0101b388 in _pt_root
 #6   0x7002053c in _pthread_body

Thread 2:
 #0   0x7003f4c8 in semaphore_wait_signal_trap
 #1   0x7003f2c8 in _pthread_cond_wait
 #2   0x01016474 in PR_WaitCondVar
 #3   0x0013f370 in nsDNSService::DequeuePendingQ(void)
 #4   0x0013ed78 in nsDNSService::Run(void)
 #5   0x05058da4 in nsThread::Main(void *)
 #6   0x0101b388 in _pt_root
 #7   0x7002053c in _pthread_body

Thread 3:
 #0   0x70044cf8 in semaphore_timedwait_signal_trap
 #1   0x70044cd8 in semaphore_timedwait_signal
 #2   0x7003f2b8 in _pthread_cond_wait
 #3   0x01016210 in pt_TimedWait
 #4   0x01016488 in PR_WaitCondVar
 #5   0x0505c804 in TimerThread::Run(void)
 #6   0x05058da4 in nsThread::Main(void *)
 #7   0x0101b388 in _pt_root
 #8   0x7002053c in _pthread_body

Thread 4:
 #0   0x70013ec8 in syscall_thread_switch
 #1   0x70814cf8 in +[NSThread sleepUntilDate:]
 #2   0x70ba1680 in -[NSUIHeartBeat _heartBeatThread:]
 #3   0x70842358 in forkThreadForFunction
 #4   0x7002053c in _pthread_body

Thread 5:
 #0   0x7003f4c8 in semaphore_wait_signal_trap
 #1   0x7003f2c8 in _pthread_cond_wait
 #2   0x01016474 in PR_WaitCondVar
 #3   0x05059ec4 in nsThreadPool::GetRequest(nsIThread *)
 #4   0x0505a818 in nsThreadPoolRunnable::Run(void)
 #5   0x05058da4 in nsThread::Main(void *)
 #6   0x0101b388 in _pt_root
 #7   0x7002053c in _pthread_body

Thread 6:
 #0   0x70000968 in mach_msg_overwrite_trap
 #1   0x700059f4 in mach_msg
 #2   0x70026a1c in _pthread_become_available
 #3   0x70026714 in pthread_exit
 #4   0x70020540 in _pthread_body

PPC Thread State:
  srr0: 0x706bab68 srr1: 0x0000f030                vrsave: 0x00000000
   xer: 0x20000004   lr: 0x70162cec  ctr: 0x706bab4c   mq: 0x00000000
    r0: 0x706cf57c   r1: 0xbfffdd60   r2: 0x02d2ec24   r3: 0x0304b7b0
    r4: 0x706cf57c   r5: 0x00000000   r6: 0xbfffe2bc   r7: 0x00000001
    r8: 0x80162c3c   r9: 0x00000029  r10: 0x001fd83b  r11: 0x00000010
   r12: 0xa67c0c03  r13: 0x00000000  r14: 0x00000000  r15: 0x00000000
   r16: 0x00000001  r17: 0x701ee5b4  r18: 0x00000002  r19: 0x40000000
   r20: 0xbfffddf8  r21: 0xbfffe2bc  r22: 0x00000004  r23: 0x00000005
   r24: 0x8016024c  r25: 0x031c9660  r26: 0x00000001  r27: 0x00000000
   r28: 0x0304b7b0  r29: 0x706bab4c  r30: 0x801608b0  r31: 0x70162c3c

Comment 1

[Max Horn]

Verified.

This is most probably caused by our workaround for that NSToolbar bug in BWC.mm, 
method toolbarWillAddItem: (see the commen there what it is about).

For now the best alternative probably is to take out this workaround and see if we can 
find a better solution for the problem.

Comment 2

[Max Horn]

Ah I should've tried first, this isn't it. So I set NSDebugEnabled and NSZombieEnabled 
and got these:

2002-08-08 18:36:45.263 Navigator[2487] *** *** Selector 'retain' sent to dealloced 
instance 0x2ae54e0 of class NSToolbarItem.
Break at '-[_NSZombie retain]' to debug.
2002-08-08 18:36:45.266 Navigator[2487] Exception raised during posting of 
notification.  Ignored.  exception: *** Selector 'retain' sent to dealloced instance 
0x2ae54e0 of class NSToolbarItem.
Break at '-[_NSZombie retain]' to debug.


So the toolbaritem is already released and then sent a retain message again.

I tried commenting out the [toolbarItem setView:mLocationToolbarView]; and indeed then 
the crash doesn't occur anymore. It's possible that still something is fishy with the code 
NSCoding "hack" we emply for the CHAutoCompleteTextField...

Comment 3

[Chris Petersen]

Confirming on the 2002-08-08-05 NB.

Comment 4

[Greg K.]

David, you probably already know this, but you should attach crash reports,
rather than commenting them.

Comment 5

[Max Horn]

This is most probably the same bug that causes bug 162022. See also 
my comment there.

Comment 6

[saari (gone)]

I don't know why this would explode and others wouldn't. Not sure what we can do
about it, pink?

Comment 7

[Max Horn]

Saari, this explodes because it is different from all other toolbar items. 
first off, it is the only one to have a NSView assigned to it. Secondly, this 
NSView contains a NSTextView subclass. NSViews that are attached to a 
toolbar item have to implement NSCoding, which luckily nearly all Apple 
NSVIews do - except NSTextView. So we have to implement ("fake") this, 
but that's near to impossible to do correctly, and obviously, we do it 
incorrectly. See bug 162022 for a possible way to solve this.

Comment 8

[David Haas (gone, not reading mail)]

I've tried Max's suggestion from 162022 (removing the text view before encoding,
adding it back in later).  It didn't work.  I've tried alloc'ing all new views,
location bars, scroll views, and autocompletetextviews every time we run through
the toolbar item creation code.  It didn't work.  I've subclassed NSToolbarItem
and overrode allowDuplicateItems to always return NO.  It didn't work.  I've
added everything but the textview, and it works - but you throw the text view in
and it bombs.  I've checked to see when things are deallocating, to see if we
can catch it in advance - it's not happening anywhere near the crash.  I've
tried overriding the validateVisibleItems method - which prevented the crash,
but the location bar wasn't visible again unless the toolbar was hidden &
redisplayed.  

I can play some more with validateVisibleItems to see if I can come up with a
clever override, but no guarantees.  And the amount of hacking to make this
textview work may not be worth the hassle.  

I could get behind going back to a text field.  

Comment 9

[Mike Pinkerton (not reading bugmail)]

dave, can you provide a patch to back all this out? thanks!

Comment 10

[David Haas (gone, not reading mail)]

Attachment: back to a text field

this changes the text view back to a text field.

undo support has been added, and I think all the current textview undo bugs are
fixed here.

only issue I've noticed is font is slightly larger than autocomplete popup
window font, but since in both cases it's the default font, I'm not going to
worry about it.  If it bothers anyone, it's easy enough to change.

that's no guarantee there aren't other problems, of course.

Comment 11

[David Haas (gone, not reading mail)]

Attachment: zipped up nib with fixes

the patch requires changes to BrowserWindow.nib, so here's my zipped up fixed
copy.

Comment 12

[Mike Pinkerton (not reading bugmail)]

landed, though i had to fix the code that selects text as the url is completed.

Comment 13

[Prachi Gauriar]

Verified fixed in my build from 8/15/2002.