105935 - Reloading a page containing a QT movie results in a crash

Status: VERIFIED FIXED

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

Description

[Robert Chin]

Application crashes as per description of bug #98729 (bug should be reopened).
http://bugzilla.mozilla.org/show_bug.cgi?id=98729

Bug regression occured in build id 2001101905

Comment 1

[Olivier Cahagne]

wfm with build 2001101909 on Win2k with QT 5.0.2 and loading/reloading following
URL: http://www.apple.com/trailers/miramax/amelie/high.html .

So I guess it's really MacOSX specific and a regression -> regression.

btw, bug original URL is a 404...

Comment 2

[Chris Petersen]

Reporter, this may not have been checked into 0.9.5 trunk build. This was fixed
in the 0.9.4 trunk last time I checked. Please go to
http://www.mozilla.org/releases/ and download the OSX 0.9.4 build. Try to
reproduce this problem if you can.

Comment 3

[Robert Chin]

This bug does not appear in mozilla build 2001-10-16-09, however it does appear
in mozilla build 2001-10-18-09 and all mozilla OS X nightly binary builds after
that.

Comment 4

[Peter Lubczynski]

Robert: This works fine for me in today's build, can you try:
http://ftp.mozilla.org/pub/mozilla/nightly/2001-10-22-12-trunk/mozilla-macosX-trunk.sit.bin
Does crash reporter give you a stack trace?

Comment 5

[Robert Chin]

Still has problems. This is what a stack trace gives me:

Program received signal EXC_BAD_ACCESS, Could not access memory.
0x04bc48a8 in ?? ()

#0  0x04bc48a8 in ?? ()
#1  0x7024cc1c in CallComponent ()
#2  0x702785ac in CallComponentOpen ()
#3  0x702604a8 in OpenAComponent ()
#4  0x7027d654 in OpenComponent ()
#5  0x73fa19c4 in OpenCodecComponent ()
#6  0x73f9e688 in DecompressSequenceBeginPrivate ()
#7  0x73fd9574 in DecompressSequenceBeginS ()
#8  0x75812984 in getNewSequence ()
#9  0x757cc17c in decompressVideoFrame ()
#10 0x7580ce7c in scrubToMediaTime ()
#11 0x757b8778 in VideoMoviesTask ()
#12 0x70249590 in CallComponentFunctionCommon ()
#13 0x757b3814 in VideoComponentDispatch ()
#14 0x7024cc1c in CallComponent ()
#15 0x70254df8 in CallComponentDispatch ()
#16 0x73f9bac4 in MediaMoviesTask ()
#17 0x73f96ae0 in TaskMovie_priv ()
#18 0x757d2f88 in doUpdateMovie ()
#19 0x757bb0e0 in internalDoAction ()
#20 0x757d0ae4 in doUpdateEvent ()
#21 0x757baf94 in internalDoAction ()
#22 0x757f0490 in _MCIdle ()
#23 0x70249418 in CallComponentFunctionCommon ()
#24 0x757c6800 in _MCComponentDispatch ()
#25 0x7024cc1c in CallComponent ()
#26 0x70254df8 in CallComponentDispatch ()
#27 0x73fab9f0 in MCIdle ()
#28 0x049b4124 in unknown_text ()
#29 0x049b5bfc in unknown_text ()
#30 0x049b0430 in unknown_text ()
#31 0x02c883d8 in
OnDataAvailable__24ns4xPluginStreamListenerFP19nsIPluginStreamInfoP14nsIInputStreamUi
()
#32 0x02c92a5c in
OnDataAvailable__26nsPluginStreamListenerPeerFP10nsIRequestP11nsISupportsP14nsIInputStreamUiUi
()
#33 0x021cd334 in
OnDataAvailable__13nsHttpChannelFP10nsIRequestP11nsISupportsP14nsIInputStreamUiUi ()
#34 0x021b0fa0 in HandleEvent__22nsOnDataAvailableEventFv ()
#35 0x021be9b4 in HandlePLEvent__23nsARequestObserverEventFP7PLEvent ()
#36 0x005dc364 in PL_HandleEvent ()
#37 0x005dc1e0 in PL_ProcessPendingEvents ()
#38 0x00583b18 in nsEventQueueImpl::ProcessPendingEvents ()
#39 0x02286028 in ProcessPLEventQueue__26nsMacNSPREventQueueHandlerFv ()
#40 0x02285dec in RepeatAction__26nsMacNSPREventQueueHandlerFRC11EventRecord ()
#41 0x022af6d8 in DoRepeaters__8RepeaterFRC11EventRecord ()
#42 0x0229aad8 in DispatchEvent__16nsMacMessagePumpFiP11EventRecord ()
#43 0x0229a6a4 in DoMessagePump__16nsMacMessagePumpFv ()
#44 0x02299f34 in Run__10nsAppShellFv ()
#45 0x020a9ce4 in Run__17nsAppShellServiceFv ()
#46 0x004baaf8 in main1__FiPPcP11nsISupports ()
#47 0x004bb680 in main ()

Comment 6

[Chris Petersen]

Looks like there was a check in done on Oct 18th that caused a regression in the
trunk builds only. The OSX branch build is functioning properly during multiple
reloads with a QT movie.

Comment 7

[Peter Lubczynski]

Okay, this is indeed a regression that started on the 18th. Looking at bonsai,
looks like dp's plugin caching when in that day.

Comment 8

[Chris Petersen]

After multiple reloads on the specified url, I get a simular stack trace:


*******

Date/Time:  2001-10-24 13:50:00 -0700
OS Version: 10.1 (Build 5L14)

Command:    Netscape 6
PID:        515

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

Thread 0:
 #0   0x04cedc08 in 0x4cedc08
 #1   0x70254df8 in CallComponentDispatch
 #2   0x70254df8 in CallComponentDispatch
 #3   0x702785ac in CallComponentOpen
 #4   0x702604a8 in OpenAComponent
 #5   0x7027d654 in OpenComponent
 #6   0x72f02ee4 in GetThisComponent
 #7   0x72f02278 in MakeSoundComponentChain
 #8   0x050e53d8 in __MixerPlaySourceBuffer
 #9   0x050e428c in MixerDispatch
 #10  0x7024cc1c in CallComponent
 #11  0x70254df8 in CallComponentDispatch
 #12  0x72f02b14 in SoundComponentPlaySourceBuffer
 #13  0x050f07b4 in __HALHardwarePlaySourceBuffer
 #14  0x050ef448 in HALHardwareDispatch
 #15  0x7024cc1c in CallComponent
 #16  0x70254df8 in CallComponentDispatch
 #17  0x72f02b14 in SoundComponentPlaySourceBuffer
 #18  0x72f01a74 in ProcessCmd
 #19  0x72f01f68 in SndDoImmediate
 #20  0x75801728 in FreshStart
 #21  0x7581d2e8 in SoundPreRollComplete
 #22  0x70249418 in CallComponentFunctionCommon
 #23  0x757c0488 in SoundComponentDispatch
 #24  0x7024cc1c in CallComponent
 #25  0x70254df8 in CallComponentDispatch
 #26  0x73fd7ed8 in MediaPreRollComplete
 #27  0x73fbe83c in prerollMedia
 #28  0x73fa474c in ForEachMedia_priv
 #29  0x73fcd66c in PrivatePrerollMovie_priv
 #30  0x73fd6778 in PrerollMovie_priv
 #31  0x757e68e0 in doMovieAction
 #32  0x757bc464 in internalDoAction
 #33  0x757e6670 in doMovieAction
 #34  0x757bc464 in internalDoAction
 #35  0x757e6a74 in doMovieAction
 #36  0x757bc464 in internalDoAction
 #37  0x7024954c in CallComponentFunctionCommon
 #38  0x757c6800 in _MCComponentDispatch
 #39  0x7024cc1c in CallComponent
 #40  0x70254df8 in CallComponentDispatch
 #41  0x73fa9814 in MCDoAction
 #42  0x05079028 in 0x5079028
 #43  0x05078bcc in 0x5078bcc
 #44  0x05073430 in 0x5073430
 #45  0x02e7dd2c in OnDataAvailable__24ns4xPluginStreamListenerFP19nsIPluginStream
 #46  0x02e87f78 in OnDataAvailable__26nsPluginStreamListenerPeerFP10nsIRequestP11
 #47  0x021caf64 in OnDataAvailable__19nsStreamListenerTeeFP10nsIRequestP11nsISupp
 #48  0x021dd598 in OnDataAvailable__13nsHttpChannelFP10nsIRequestP11nsISupportsP1
 #49  0x021c42c8 in nsOnDataAvailableEvent::HandleEvent(void)
 #50  0x021d0534 in nsARequestObserverEvent::HandlePLEvent(PLEvent *)
 #51  0x005dcc00 in PL_HandleEvent
 #52  0x005dca7c in PL_ProcessPendingEvents
 #53  0x00584f54 in nsEventQueueImpl::ProcessPendingEvents(void)
 #54  0x0230cb28 in nsMacNSPREventQueueHandler::ProcessPLEventQueue(void)
 #55  0x0230c8ec in nsMacNSPREventQueueHandler::RepeatAction(EventRecord const &)
 #56  0x023351a8 in Repeater::DoRepeaters(EventRecord const &)
 #57  0x02320cfc in nsMacMessagePump::DispatchEvent(int, EventRecord *)
 #58  0x0232061c in nsMacMessagePump::DoMessagePump(void)
 #59  0x0231feac in nsAppShell::Run(void)
 #60  0x020c113c in nsAppShellService::Run(void)
 #61  0x004bbf28 in main1(int, char **, nsISupports *)
 #62  0x004bcca8 in main

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   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

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

Thread 9:
 #0   0x70034d68 in semaphore_wait_trap
 #1   0x70009fa0 in pthread_mutex_lock
 #2   0x70241684 in TSLockMutex
 #3   0x050f534c in SMGrabMutex
 #4   0x050e67b8 in __MixerGetSourceData
 #5   0x050e41d4 in MixerDispatch
 #6   0x7024cc1c in CallComponent
 #7   0x70254df8 in CallComponentDispatch
 #8   0x72f01174 in SoundComponentGetSourceData
 #9   0x050f101c in sdevFillBufferList
 #10  0x050f0e04 in sdevAudioDeviceIOProc
 #11  0x706012c0 in XBasicDevice::CallIOProcs(AudioTimeStamp const *,
AudioTimeStamp const *, AudioTimeStamp const *)
 #12  0x706197e0 in XThreadedDevice::HandleIO(AudioTimeStamp const &, bool)
 #13  0x7061a160 in XThreadedDevice::IOThread(void)
 #14  0x7060e484 in XThreadedDevice::IOThreadEntry(void *)
 #15  0x706141c0 in CAPThread::Entry(CAPThread *)
 #16  0x70020efc in _pthread_body


PPC Thread State:
  srr0: 0x04cedc08 srr1: 0x0200f030                vrsave: 0x00000000
   xer: 0x00000016   lr: 0x7024cc1c  ctr: 0x04cedc00   mq: 0x00000000
    r0: 0x04cedc00   r1: 0xbfffd7f0   r2: 0xbfffcf6a   r3: 0xbfffd8c8
    r4: 0x00000000   r5: 0xbfffd91c   r6: 0xbfffd920   r7: 0x00000000
    r8: 0x00000084   r9: 0x014d2ef0  r10: 0x00000084  r11: 0x014d3050
   r12: 0x05475308  r13: 0x00000000  r14: 0x00000033  r15: 0x0004a010
   r16: 0xbfffee70  r17: 0x00000000  r18: 0x00000014  r19: 0x0000342b
   r20: 0x00000000  r21: 0x0000001c  r22: 0x70004bc4  r23: 0x70004c58
   r24: 0x00000001  r25: 0x0004b060  r26: 0x00000000  r27: 0x0005e0f0
   r28: 0x00000000  r29: 0xbfffef00  r30: 0x00000000  r31: 0x00000001

**********

Comment 9

[Suresh Duddi (gone)]

Damn. Wonder how plugin cache would interfere - it certainly causes the dll to
get loaded way way later, only when it is required. But after it is loaded, the
cache is out of way.

So per the report loading the page shows the plugin fine but reloading causing
the crash right ?

No bright ideas here. Need to look at whats going on. Reassign to me if you want
me to look at it.

Comment 10

[Peter Lubczynski]

Could you take a look? I can help with anything you need. This problem stems
from bug 98729. For some reason, Quicktime doesn't like when it's bundle is
released and unloaded and then later reloaded again. I put in a hack to set
mCanUnloadLibrary to false if the plugin is a "bundle" on Mac which prevents
unloading until shutdown. It's possible that the real problem is that we missing
a step upon loading the plugin when it's been cached.

Comment 11

[Peter Lubczynski]

Ahh, I see why the hack is failing. Instead of holding around a bool for the
bundle in nsPluginTag, I just set mCanUnloadLibrary right away in the copy
constructor. Therefore when the plugins are read from the registry on startup
instead of querying the plugin, that flag is lost. :(

Comment 12

[Suresh Duddi (gone)]

Thanks Peter. I follow this now. Possible fixes are:

a) store the mCanUnloadLibrary info into the registry and load it back
   - easiest and non platform dependent fix

b) after loading a plugin refigure out whether it can be unloaded or not.
   - will require platform dependent code I think.

I will try (a). Let me know if (b) is preferable.

Comment 13

[Suresh Duddi (gone)]

Attachment: Persistent Caching of canunload flag

Comment 14

[Peter Lubczynski]

Comment on attachment 55087 [details] [diff] [review]
Persistent Caching of canunload flag

r=peterl I think that'll work!

Comment 15

[Suresh Duddi (gone)]

waterson : sr?

Comment 16

[Chris Waterson]

Comment on attachment 55087 [details] [diff] [review]
Persistent Caching of canunload flag

sr=waterson

Comment 17

[Suresh Duddi (gone)]

Fix checked in.

Comment 18

[Chris Petersen]

*** Bug 107298 has been marked as a duplicate of this bug. ***

Comment 19

[Chris Petersen]

Marking verified in the Nov 1 Mac OS X trunk build (2001-11-01-08). Tested with
Mac OS X 10.1.

Comment 20

[Peter Lubczynski]

nominating for branch

Comment 21

[Judson Valeski]

minusing. 0.9.4 isn't targeting mac.

Comment 22

[Peter Lubczynski]

Yes, but this is fixing a regression in bug 101769 which is also trying to make
it into the branch. we need this fix so that both branches will be in sync,
especially since this revs the plugin startup cache registry version. nominating
again...

Comment 23

[Judson Valeski]

101769 is a perf bug (which we aren't taking for the branch right now), I'm
minusing this again. again, if we're still in the dark, please re-nominate :-)