102727 - OSX: Crash occurs after selecting QT Plugin menu items (Plug-in Settings / Connection speed)

Status: VERIFIED FIXED

(Core Graveyard :: Plug-ins, defect, P3)

Description

[Chris Petersen]

Build: Branch 2001100204 
Platform : OS X
Expected Results: Qt prefs windows should open.
What I got: Application crashes
Steps to reproduce:

1) Go to http://ltg.coca-cola.com/
2) Select Quicktime from menu 
3) Click on Play button below US English text.
4) This will cause JS window to appear with embeded QT movie
5) Click on qt movie controller to display popup menu.
6) Select either Plug-in settings or Connection speed.
7) Application should crash

Comment 1

[Chris Petersen]

Attachment: Reduced test case of various samples

Comment 2

[Chris Petersen]

The sample test cause has four different links:

1) link - JS window created with original movie source from page
2) link - Instead of JS window , movie loads in a browser window via target
attribute
3) link - JS window created like the first link except it's using a different
movie source
4) link JS window created like the first and third link. The difference is it
uses HTML to insert the movie.

The crash only occurs for me with link 1 and 3. They both insert a raw QT movie
(No html) in a JS created window. 

Comment 3

[Chris Petersen]

This appears to be a Mac OS X issue since I can't reproduce under OS 9.1 or
Windows ME.

Comment 4

[Chris Petersen]

If feel this is a serious issue since it happens with a popular site. Accessing
the QT plugin setting from the QT plugin is pretty common.

Comment 5

[Peter Lubczynski]

taking....but I don't think it's that common. The crash only happens when going
to prefrences via the context menu in a quicktime movie while it's in full-page
mode being displayed by a javascript popup only on OS X.

Comment 6

[Chris Petersen]

I guess it's subjective on how common it is. Users will use it as a shortcut to
the QT preference settings. I would like to see this fixed...

Comment 7

[Chris Petersen]

Stack trace from crash reporter under Mac OS X 10.1

Date/Time:  2001-10-01 10:51:44 -0700
OS Version: 10.1 (Build 5G64)

Command:    Netscape 6
PID:        301

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at 0x0000002d

Thread 0:
 #0   0x02a0c04c in 0x2a0c04c
 #1   0x00000000 in 0x0
 #2   0x02a09fcc in 0x2a09fcc
 #3   0x0211531c in 0x211531c
 #4   0x021153a4 in 0x21153a4
 #5   0x02115458 in 0x2115458
 #6   0x02121880 in 0x2121880
 #7   0x021201c8 in 0x21201c8
 #8   0x0211f804 in 0x211f804
 #9   0x021235c0 in 0x21235c0
 #10  0x02125dc0 in 0x2125dc0
 #11  0x02125b8c in 0x2125b8c
 #12  0x021253c4 in 0x21253c4
 #13  0x021250a0 in 0x21250a0
 #14  0x02124bd8 in 0x2124bd8
 #15  0x01e4a208 in 0x1e4a208
 #16  0x004ba698 in 0x4ba698
 #17  0x004bb038 in 0x4bb038

Thread 1:
 #0   0x7000530c in syscall
 #1   0x70557590 in BSD_waitevent
 #2   0x70554a30 in CarbonSelectThreadFunc
 #3   0x70020efc in _pthread_body

Thread 2:
 #0   0x7003fe48 in semaphore_wait_signal_trap
 #1   0x7003fc48 in _pthread_cond_wait
 #2   0x705594ac in CarbonOperationThreadFunc
 #3   0x70020efc in _pthread_body

Thread 3:
 #0   0x70043988 in semaphore_timedwait_signal_trap
 #1   0x70043968 in semaphore_timedwait_signal
 #2   0x7003fc38 in _pthread_cond_wait
 #3   0x7028366c in TSWaitOnConditionTimedRelative
 #4   0x7027cf10 in TSWaitOnSemaphoreCommon
 #5   0x702c14c8 in TimerThread
 #6   0x70020efc in _pthread_body

Thread 4:
 #0   0x7003fe48 in semaphore_wait_signal_trap
 #1   0x7003fc48 in _pthread_cond_wait
 #2   0x702505cc in TSWaitOnCondition
 #3   0x7027cef8 in TSWaitOnSemaphoreCommon
 #4   0x7024386c in AsyncFileThread
 #5   0x70020efc in _pthread_body

Thread 5:
 #0   0x7003fe48 in semaphore_wait_signal_trap
 #1   0x7003fc48 in _pthread_cond_wait
 #2   0x7055b9b4 in CarbonInetOperThreadFunc
 #3   0x70020efc in _pthread_body

Thread 6:
 #0   0x70001308 in mach_msg_overwrite_trap
 #1   0x70006394 in mach_msg
 #2   0x7017bebc in __CFRunLoopRun
 #3   0x701b6ba0 in CFRunLoopRunSpecific
 #4   0x7017b804 in CFRunLoopRunInMode
 #5   0x7061be08 in
XIOAudioDeviceManager::NotificationThread(XIOAudioDeviceManager *)
 #6   0x706141c0 in CAPThread::Entry(CAPThread *)
 #7   0x70020efc in _pthread_body

Thread 7:
 #0   0x70043988 in semaphore_timedwait_signal_trap
 #1   0x70043968 in semaphore_timedwait_signal
 #2   0x7003fc38 in _pthread_cond_wait
 #3   0x70623878 in CAGuard::WaitFor(unsigned long long)
 #4   0x70623954 in CAGuard::WaitUntil(unsigned long long)
 #5   0x7061a0d4 in XThreadedDevice::IOThread(void)
 #6   0x7060e484 in XThreadedDevice::IOThreadEntry(void *)
 #7   0x706141c0 in CAPThread::Entry(CAPThread *)
 #8   0x70020efc in _pthread_body

Thread 8:
 #0   0x70001308 in mach_msg_overwrite_trap
 #1   0x70006394 in mach_msg
 #2   0x700273dc in _pthread_become_available
 #3   0x700270d4 in pthread_exit
 #4   0x70020f00 in _pthread_body


PPC Thread State:
  srr0: 0x02a0c04c srr1: 0x0000f030                vrsave: 0x00000000
   xer: 0x20000020   lr: 0x02a09fcc  ctr: 0x0211c290   mq: 0x00000000
    r0: 0x02a09fcc   r1: 0xbfffeea0   r2: 0x02662000   r3: 0x00000001
    r4: 0xbffff0bc   r5: 0xbffff018   r6: 0x00000000   r7: 0x00000001
    r8: 0x00000001   r9: 0x00000000  r10: 0x00000151  r11: 0x0001013b
   r12: 0x0217f53c  r13: 0x00000000  r14: 0x00000036  r15: 0xbfffee58
   r16: 0xbfffee70  r17: 0x00000001  r18: 0x0066ff48  r19: 0x0000120b
   r20: 0x00000000  r21: 0x0000001c  r22: 0x70004bc4  r23: 0x70004c58
   r24: 0x00000001  r25: 0x000006eb  r26: 0x8081ab5c  r27: 0x0005bbc0
   r28: 0x00000000  r29: 0xbfffef00  r30: 0x8081d1cc  r31: 0x00000001

**********

Comment 8

[Peter Lubczynski]

The thrid link in the testcase is the only one that crashes for me. Here's a
better trace:

 #0   0x01c80cd4 in ProcessEvent__19pluginInstanceOwnerFRC10nsGUIEvent
 #1   0x02306808 in 0x2306808
 #2   0x01c7c2a4 in HandlePluginEvent__FP10nsGUIEvent
 #3   0x0228c254 in DispatchEvent__8nsWindowFP10nsGUIEventR13nsEventStatus
 #4   0x0228c34c in DispatchWindowEvent__8nsWindowFR10nsGUIEvent
 #5   0x0228c4b0 in DispatchMouseEvent__8nsWindowFR12nsMouseEvent
 #6   0x022a0cd0 in HandleMouseMoveEvent__17nsMacEventHandlerFR11EventRecord
 #7   0x0229e9c8 in HandleOSEvent__17nsMacEventHandlerFR11EventRecord
 #8   0x0229d1bc in HandleOSEvent__11nsMacWindowFR11EventRecord
 #9   0x022a3eb4 in DispatchOSEvent__16nsMacMessageSinkFR11EventRecordP15OpaqueWin
 #10  0x022a9024 in DispatchOSEventToRaptor__16nsMacMessagePumpFR11EventRecordP15O
 #11  0x022a8c28 in DoMouseMove__16nsMacMessagePumpFR11EventRecord
 #12  0x022a825c in DispatchEvent__16nsMacMessagePumpFiP11EventRecord
 #13  0x022a7e28 in DoMessagePump__16nsMacMessagePumpFv

Comment 9

[Peter Lubczynski]

edgecase--->mozilla1.0

Comment 10

[Steve Dagley]

This bug is on the list of Mac bugs identified as significant enough to merit
fixing for MachV - adding nsbeta1 keyword.

And I can confirm the crash still occurs for me with the 098 build but the stack
trace is somewhat different:

Thread 0 Crashed:
 #0   0x0294a2dc in pluginInstanceOwner::ProcessEvent(nsGUIEvent const &)
 #1   0x020b58a4 in nsBaseWidget::Enumerator::Release( (void))
 #2   0x02946e24 in HandlePluginEvent(nsGUIEvent *)
 #3   0x020ac8c4 in nsWindow::DispatchEvent(nsGUIEvent *, nsEventStatus &)
 #4   0x020ac99c in nsWindow::DispatchWindowEvent(nsGUIEvent &)
 #5   0x020acae8 in nsWindow::DispatchMouseEvent(nsMouseEvent &)
 #6   0x020bdd30 in nsMacEventHandler::HandleMouseMoveEvent(EventRecord &)
 #7   0x020bc27c in nsMacEventHandler::HandleOSEvent(EventRecord &)
 #8   0x020bb064 in nsMacWindow::DispatchEvent(void *, int *)
 #9   0x020c2bc0 in DispatchOSEventToRaptor__16nsMacMessagePumpFR11EventRecordP15O
 #10  0x020c2858 in nsMacMessagePump::DoMouseMove(EventRecord &)
 #11  0x020c1a9c in nsMacMessagePump::DispatchEvent(int, EventRecord *)
 #12  0x020c16d0 in nsMacMessagePump::DoMessagePump(void)
 #13  0x020c100c in nsAppShell::Run(void)
 #14  0x02076e4c in nsAppShellService::Run(void)
 #15  0x004c8bb4 in main1(int, char **, nsISupports *)
 #16  0x004c968c in main

That was with the 3rd link in the testcase. 

Comment 11

[Peter Lubczynski]

I can reproduce by clicking on a disabled menu item. Debugger isn't being too
friendly, trying printf's

Comment 12

[Peter Lubczynski]

Attachment: patch v.1

It looked like the cause of the crash was some erroneous events being passed to
us from the widget. This patch takes a more defensive approach to passing
events to the plugin by ensure the event was really meant for our plugin's
widget. Please review.

Comment 13

[Mike Pinkerton (not reading bugmail)]

so my question is why are we getting bad widgets passed to the plugin code?
seems like that's the right fix in addition to making the plugin more robust.

Comment 14

[Peter Lubczynski]

I think the plugin is getting it because it's the "lastWidgetHit" in
|nsMacEventHandler::HandleMouseMoveEvent|. The widget in the event isn't the
widget that's created for the full-page plugin, but it does look like a valid
one in the debugger. Looking in |nsWindow::DispatchWindowEvent|,
this->mEventCallback doesn't match mEventCallback of the event's widget either.
The plugin-side fix seemed safest to me.

Comment 15

[Brian Nesse (gone)]

Not that I'm against additional validation checks, but it seems to me that, if I
understand correctly, the plugin code is not really at fault here... fixing the
plug-in may leave other crashers lying around.

Do I understand correctly, that you suspect |lastWidgetHit| represents the
plug-in... even though it is not the most recently "hit" object (which I expect
would now be the context menu instead...)? If that's the case, shouldn't
|lastWidgetHit| be pointing to the context menu, or the new window, or whatever
is now really frontmost, or nothing at all if that's more appropriate?

cc'ing saari for some mac event insight...

Comment 16

[Winnie Lam]

adding adt1 to status whiteboard as per discussion with beppe.

Comment 17

[rubydoo123]

reduce the urgency on this bug: the scenario is this --

you have to be on OSX, it has to be a js pop-up window with a full-page QT and 
you must select a disabled menu item on the pop-up. Enabled items do not crash.

Comment 18

[Peter Lubczynski]

Comment on attachment 71397 [details] [diff] [review]
patch v.1

I'm sticking by this patch. I think it's the right fix for this bug. It kinda
makes sense that the plugin's widget would get the event if it happened in a
native widget created by the plugin like the context menu. Where else is the
event supposed to go? We have no widget to corespond with the native context
menu. Our nearest thing is the plugin's widget which gets the event. I'm
willing to leave this bug open or open or open a new one and check-in this
band-aid to stop the crash.

Comment 19

[Brian Nesse (gone)]

Comment on attachment 71397 [details] [diff] [review]
patch v.1

>I think it's the right fix for this bug...
Ok. r=bnesse

Comment 20

[Marc Attinasi]

Comment on attachment 71397 [details] [diff] [review]
patch v.1

sr=attinasi

Comment 21

[Jaime Rodriguez, Jr.]

adt1.0.0+ (on ADT's behalf) for approval for checkin. Its good to get the
crashers out.

Comment 22

[Asa Dotzler [:asa]]

Comment on attachment 71397 [details] [diff] [review]
patch v.1

a=asa (on behalf of drivers) for checkin to the 1.0 trunk

Comment 23

[Peter Lubczynski]

Patch in trunk (before branching), marking FIXED.

Comment 24

[shrirang khanzode]

all tests working ok on 2002040411 trunk on os x, no crash seen. verif.