Closed Bug 98729 Opened 23 years ago Closed 23 years ago

Reloading a page containing a QT movie results in a crash

Categories

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

PowerPC
macOS
defect

Tracking

(Not tracked)

VERIFIED FIXED
mozilla0.9.5

People

(Reporter: chrispetersen, Assigned: peterlubczynski-bugs)

References

()

Details

(Keywords: crash, Whiteboard: PDT+ [OSX+])

Attachments

(2 files)

Build: 2001090705 Platform: Mac OS X Expected Results: Reloading the page shouldn't result in a crash What I got: Application crashes Steps to reproduce: 1) Go to http://www.apple.com/macosx/theater/finder.html 2) Page contains a QT movie and will start to play automatically 3) While movie plays, click the reload button. 4) Page starts to reload it's content then crashes. Stack trace: ********** Date/Time: 2001-09-07 10:19:00 -0700 PID: 243 Command: Netscape 6 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_INVALID_ADDRESS (0x0001) at 0x0430d140 Thread 0: #0 0x04531148 in 0x4531148 () #1 0x75b89020 in _MediaSTGetSampleDescriptionCnt () #2 0x7027c99c in _CallComponentDispatch () #3 0x7027c96c in _CallComponentOpen () #4 0x7027bbec in _OpenAComponent () #5 0x7027b9f4 in _OpenComponent () #6 0x75b756f4 in _OpenCodecComponent () #7 0x75b7509c in _DecompressSequenceBeginPrivate () #8 0x75b8fc7c in _DecompressSequenceBeginS () #9 0x019600c4 in _getNewSequence () #10 0x01965424 in _decompressVideoFrame () #11 0x0195f20c in _scrubToMediaTime () #12 0x0195d6e8 in _VideoMoviesTask () #13 0x702963c0 in _CallComponentFunctionCommon () #14 0x70296648 in _CallComponentFunctionWithStorageProcInfo () #15 0x0195b938 in _VideoComponentDispatch () #16 0x7027ca88 in _CallComponent () #17 0x7027c99c in _CallComponentDispatch () #18 0x75b8ed68 in _MediaMoviesTask () #19 0x75b8e408 in _TaskMovie_priv () #20 0x019c5dac in _doIdleMovie () #21 0x019cf490 in _internalDoAction () #22 0x019c4c00 in __MCIdle () #23 0x70296248 in _CallComponentFunctionCommon () #24 0x70296648 in _CallComponentFunctionWithStorageProcInfo () #25 0x019c3dfc in __MCComponentDispatch () #26 0x7027ca88 in _CallComponent () #27 0x7027c99c in _CallComponentDispatch () #28 0x75b94dd4 in _MCIdle () #29 0x045f2c68 in 0x45f2c68 () #30 0x045f479c in 0x45f479c () #31 0x045ef304 in 0x45ef304 () #32 0x02c32d4c in OnDataAvailable__24ns4xPluginStreamListenerFP19nsIPluginStream () #33 0x02c3cfb8 in OnDataAvailable__26nsPluginStreamListenerPeerFP10nsIRequestP11 () #34 0x022b496c in OnDataAvailable__19nsStreamListenerTeeFP10nsIRequestP11nsISupp () #35 0x022c75a4 in OnDataAvailable__13nsHttpChannelFP10nsIRequestP11nsISupportsP1 () #36 0x022adcd0 in HandleEvent__22nsOnDataAvailableEventFv () #37 0x022b9f3c in HandlePLEvent__23nsARequestObserverEventFP7PLEvent () #38 0x001ba458 in PL_HandleEvent () #39 0x001ba2d4 in PL_ProcessPendingEvents () #40 0x00162b58 in ProcessPendingEvents__16nsEventQueueImplFv () #41 0x023f2850 in ProcessPLEventQueue__26nsMacNSPREventQueueHandlerFv () #42 0x023f2614 in RepeatAction__26nsMacNSPREventQueueHandlerFRC11EventRecord () #43 0x0241805c in DoRepeaters__8RepeaterFRC11EventRecord () #44 0x02406bb4 in DispatchEvent__16nsMacMessagePumpFiP11EventRecord () #45 0x024064d4 in DoMessagePump__16nsMacMessagePumpFv () #46 0x02405d64 in Run__10nsAppShellFv () #47 0x020c9424 in Run__17nsAppShellServiceFv () #48 0x00093834 in main1__FiPPcP11nsISupports () #49 0x00094470 in main () Thread 1: #0 0x7000424c in _syscall () #1 0x706584b8 in _ProcessReadyEvent () #2 0x706582b0 in _CarbonSelectThreadFunc () #3 0x70014f04 in __pthread_body () Thread 2: #0 0x70059b68 in _semaphore_wait_signal_trap () #1 0x70016110 in _semaphore_wait_signal () #2 0x70015f78 in __pthread_cond_wait () #3 0x70015d18 in _pthread_cond_wait () #4 0x70653be0 in _BSD_pthread_cond_wait () #5 0x70653bc0 in _CarbonConditionWait () #6 0x7065557c in _CarbonOperationThreadFunc () #7 0x70014f04 in __pthread_body () Thread 3: #0 0x70059b48 in _semaphore_timedwait_signal_trap () #1 0x7003f7f8 in _semaphore_timedwait_signal () #2 0x70015f68 in __pthread_cond_wait () #3 0x7003f7c4 in _pthread_cond_timedwait_relative_np () #4 0x7029b590 in _TSWaitOnConditionTimedRelative () #5 0x7029cdac in _TSWaitOnSemaphoreCommon () #6 0x702e5f98 in _TSWaitOnSemaphoreRelative () #7 0x702e7208 in _TimerThread () #8 0x70014f04 in __pthread_body () Thread 4: #0 0x70059b68 in _semaphore_wait_signal_trap () #1 0x70016110 in _semaphore_wait_signal () #2 0x70015f78 in __pthread_cond_wait () #3 0x70015d18 in _pthread_cond_wait () #4 0x7029b550 in _TSWaitOnCondition () #5 0x7029cd94 in _TSWaitOnSemaphoreCommon () #6 0x7029cce4 in _TSWaitOnSemaphore () #7 0x7029cba8 in _AsyncFileThread () #8 0x70014f04 in __pthread_body () Thread 5: #0 0x70059b68 in _semaphore_wait_signal_trap () #1 0x70016110 in _semaphore_wait_signal () #2 0x70015f78 in __pthread_cond_wait () #3 0x70015d18 in _pthread_cond_wait () #4 0x70653be0 in _BSD_pthread_cond_wait () #5 0x70653bc0 in _CarbonConditionWait () #6 0x70653ab4 in _CarbonInetOperThreadFunc () #7 0x70014f04 in __pthread_body () Thread 6: #0 0x700007b8 in _mach_msg_overwrite_trap () #1 0x700056e4 in _mach_msg_overwrite () #2 0x700277b0 in _thread_suspend () #3 0x70027744 in __pthread_become_available () #4 0x70027468 in _pthread_exit () #5 0x70014f08 in __pthread_body () PPC Thread State: srr0: 0x04531148 srr1: 0x0000f030 vrsave: 0x00000000 xer: 0x00000008 lr: 0x7027ca88 ctr: 0x700155b0 mq: 0x00000000 r0: 0x00000088 r1: 0xbfffdd10 r2: 0x039b2000 r3: 0xbfffddd8 r4: 0x00000000 r5: 0xbfffde2c r6: 0xbfffde30 r7: 0x00000000 r8: 0x00000088 r9: 0x04531140 r10: 0x00000088 r11: 0x013b5370 r12: 0x0430d140 r13: 0x00000040 r14: 0x04525656 r15: 0x00000000 r16: 0x00000000 r17: 0x00000000 r18: 0x00000000 r19: 0x53565131 r20: 0x04599000 r21: 0x00000000 r22: 0xbfffdf74 r23: 0x00000000 r24: 0x00000000 r25: 0x00000000 r26: 0x00000000 r27: 0xbfffdea8 r28: 0xbfffddd8 r29: 0x0088000d r30: 0x0000000d r31: 0x7027c9c0 **********
This bug is a offshoot of http://bugzilla.mozilla.org/show_bug.cgi?id=91988. Which was resolved but contained additional steps to reproduce multiple crashes.
Steve dagley comments from bug 91988 shows a stack trace that is simular: ------- Additional Comments From sdagley@netscape.com 2001-07-23 21:03 ------- Ok, got Crash Reporter working an here's what it kicked out: Date/Time: 2001-07-23 20:52:40 -0700 PID: 249 Command: Netscape 6Debug Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_INVALID_ADDRESS (0x0001) at 0x01746140 Thread 0: #0 0x054c3b28 in 0x54c3b28 () #1 0x75b89020 in _MediaSTGetSampleDescriptionCnt () #2 0x7027c99c in _CallComponentDispatch () #3 0x7027c96c in _CallComponentOpen () #4 0x7027bbec in _OpenAComponent () #5 0x7027b9f4 in _OpenComponent () #6 0x75b756f4 in _OpenCodecComponent () #7 0x75b7509c in _DecompressSequenceBeginPrivate () #8 0x75b8fc7c in _DecompressSequenceBeginS () #9 0x01b6b0c4 in _getNewSequence () #10 0x01b70424 in _decompressVideoFrame () #11 0x01b6a20c in _scrubToMediaTime () #12 0x01b686e8 in _VideoMoviesTask () #13 0x702963c0 in _CallComponentFunctionCommon () #14 0x70296648 in _CallComponentFunctionWithStorageProcInfo () #15 0x01b66938 in _VideoComponentDispatch () #16 0x7027ca88 in _CallComponent () #17 0x7027c99c in _CallComponentDispatch () #18 0x75b8ed68 in _MediaMoviesTask () #19 0x75b8e408 in _TaskMovie_priv () #20 0x01bd1284 in _doUpdateMovie () #21 0x01bda4f4 in _internalDoAction () #22 0x01bd0904 in _doUpdateEvent () #23 0x01bda404 in _internalDoAction () #24 0x01bcfc00 in __MCIdle () #25 0x70296248 in _CallComponentFunctionCommon () #26 0x70296648 in _CallComponentFunctionWithStorageProcInfo () #27 0x01bcedfc in __MCComponentDispatch () #28 0x7027ca88 in _CallComponent () #29 0x7027c99c in _CallComponentDispatch () #30 0x75b94dd4 in _MCIdle () #31 0x054aec68 in 0x54aec68 () #32 0x054b079c in 0x54b079c () #33 0x054ab304 in 0x54ab304 () #34 0x03109060 in OnDataAvailable__24ns4xPluginStreamListenerFP19nsIPluginStream () #35 0x03118214 in OnDataAvailable__26nsPluginStreamListenerPeerFP10nsIRequestP11 () #36 0x024f40b8 in OnDataAvailable__13nsHttpChannelFP10nsIRequestP11nsISupportsP1 () #37 0x024d1568 in HandleEvent__22nsOnDataAvailableEventFv () #38 0x024e2764 in HandlePLEvent__23nsARequestObserverEventFP7PLEvent () #39 0x00214900 in PL_HandleEvent () #40 0x002146ac in PL_ProcessPendingEvents () #41 0x001a04d0 in ProcessPendingEvents__16nsEventQueueImplFv () #42 0x001a05a0 in ProcessPendingEvents__16nsEventQueueImplFv () #43 0x0262d320 in ProcessPLEventQueue__26nsMacNSPREventQueueHandlerFv () #44 0x0262cd10 in RepeatAction__26nsMacNSPREventQueueHandlerFRC11EventRecord () #45 0x02666368 in DoRepeaters__8RepeaterFRC11EventRecord () #46 0x026469d4 in DispatchEvent__16nsMacMessagePumpFiP11EventRecord () #47 0x02646080 in DoMessagePump__16nsMacMessagePumpFv () #48 0x02645708 in Run__10nsAppShellFv () #49 0x0235a2ec in Run__17nsAppShellServiceFv () #50 0x0009b25c in main1__FiPPcP11nsISupports () #51 0x0009e2b8 in main () Entries #1 to #30 are in the QT plugin code or QT code itself Entries #0 and #31 to #33 are unknown Entries #34 to #51 are in Mozilla
Here is Steve's original steps for the Quicktime crash: ------- Additional Comments From sdagley@netscape.com 2001-08-20 20:28 ------- Hate to be the bearer of bad tidings but this doesn't fix the QuickTime crash for me (trunk build froma clean pull today w/patch applied). I have a slightly different test case though: 1) Go to http://www.apple.com/trailers/disney/monsters_inc/ 2) Click on "WATCH THE NEW TRAILER" 3) Pick a movie size from the window that pops up 4) Click in the window that pops up to start the movie playing 5) Move the movie window out of the way so you can click on "WATCH THE NEW TRAILER" again 6) Pick the same size movie as you did in step #3 7) Note the movie from step #4 stops playing and you get the "click to play" message displayed again 8) Click in the movie window to start playing 9) Observe that you crash
Keywords: nsenterprise+
Likley caused by loading the plugin resources too often for bundle-type plugins.
Assignee: av → peterlubczynski
Keywords: crash
Priority: -- → P1
Target Milestone: --- → mozilla0.9.5
my os x woes will be fixed next week .I do not have a permanent m/c to test this :(. Will get an installation early next week. isn't this bug 91988 ?
*** Bug 98505 has been marked as a duplicate of this bug. ***
Attached patch possible patch (deleted) — Splinter Review
That last attachment patches the crash by skipping the call to PR_UnloadLibrary(). It does not fix the root of the cause, just covers it up.
Status: NEW → ASSIGNED
Keywords: patch
Keywords: nsenterprise+nsbranch
Hi, Peter: So what's your plan now? Just use the last patch or working on finding new solution? Will you be able to fix this for M0.9.5? Thx.
Keywords: nsenterprise+
*** Bug 99294 has been marked as a duplicate of this bug. ***
Peter, based on your comment of 09/10 it smells to me like we're not telling the plugin to stop/unload before we PR_UnloadLibrary() it which would be a Bad Thing™. Any ideas there?
I don't think that's the problem. I can verify that Stop() and Shutdown() are being called. You can see the calls by setting NSPRLogModules=Plugin:5,PluginNPN:5,PluginNPP:5 I'm not quite sure what the problem is exactly yet. I now suspect either something in PR_UnloadLibrary() or the plugin directory scan. During the plugin directory scan, we load plugin resources (and open the bundle) to get certain info. The problem could be with this initial open/close of the bundle/resources. However, I wonder if not unloading the library may cause us to leak every time we load the plugin. Perhaps a better way would be to piggy back on the voluntary plugin caching already implemented for XPCOM and scripting plugins. I found the problem with this approach is that for some reason we unload these "cached" plugins next time we re-encounter them. I'm not sure what the reason behind this is or if it's a bug, but I may be able to "flag" the plugin in a special way.
Blocks: 96015
It seems this crash happens when the bundle is destroyed by calling CFRelease: http://lxr.mozilla.org/mozilla/source/nsprpub/pr/src/linking/prlink.c#1109 When this was commented out, the crash stopped. The good news is that at least we don't keep leaking. NSPR finds the correct library when it's loaded a second time so the ref count of the bundle just goes up. I wonder if it's this "caching" that is causing the problem because it happens when the refcount of the bundle hits zero. I'll investigate further but cc:ing wtc. Does anyone know what the is the significance or problems are in possibly fixing this by doing a CFRetain in plugin code on the bundle when we initially load it? Would this cause problems in removing the library when it's not running?
Check in today on the branch and trunk. Mark it fixed and open a new bug for the leak.
Keywords: nsbranchnsbranch+
Whiteboard: PDT+
That last patch ensures that we only do this hack for bundle-type plugins on a CARBON build. I'm now seeking reviews... I tested the following: * Reloading THIS testcase * Reloadina about:plugins * Little Monster's testcase * Removing plugin from Internet Plugins while browser is running and re-tested above
Whiteboard: PDT+ → PDT+ [seeking reviews]
I wonder if loading the bundle multiple times is the culprit. Patch looks reasonable for a workaround fix. r=beard
Comment on attachment 49852 [details] [diff] [review] slightly better patch (same approach as other patch) sr=attinasi
Attachment #49852 - Flags: superreview+
Whiteboard: PDT+ [seeking reviews] → PDT+ [seeking reviews] [OSX+]
Whiteboard: PDT+ [seeking reviews] [OSX+] → PDT+ [OSX+] [checkin pending tree opening]
Blocks: 90251
patch is in the trunk
Whiteboard: PDT+ [OSX+] [checkin pending tree opening] → PDT+ [OSX+] [patch in trunk]
Pls update Patch Status with "has-review", and bring it to the PDt tomorrow.
Comment on attachment 49852 [details] [diff] [review] slightly better patch (same approach as other patch) huh? I'm confused. This bug already has a PDT+ and a r=beard. I was planning on landing it soon.
Attachment #49852 - Flags: review+
chekc it into the branch today.
patch in branch, marking FIXED
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Whiteboard: PDT+ [OSX+] [patch in trunk] → PDT+ [OSX+]
Works great now. Marking verified in the Mac OS X trunk build (2001-09-21-20) and Mac OS X branch (2001-09-24-04).
Status: RESOLVED → VERIFIED
Ah! Its back.... Sysetm: 10.1, Quicktime 5.0.2; Build: 2001102205; I didnt know if I should have "Reopen bug" so Ill leave that to you guys =)
This appears to be a problem for others as well. Check Macintouch. http://www.macintouch.com/mosxreaderreports61.html#oct23 Scroll to the note from Doug Metz. I don't know what browser Doug & Michael are talking about, but it's possible this is a Security Update/10.1/QT/QT plugin problem and not a Fizzilla problem. - Adam
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. For the new regression , please put your comments in http://bugzilla.mozilla.org/show_bug.cgi?id=105935
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: