Closed Bug 54186 Opened 24 years ago Closed 24 years ago

crash when opening a shockwave movie while another shockwave movie is streaming in SW8.5

Categories

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

PowerPC
Mac System 8.6
defect

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: kcunningham, Assigned: peterl-retired)

References

()

Details

(Keywords: crash, shockwave, Whiteboard: [rtm++] [r=av sr=buster])

Attachments

(6 files)

From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Mac_PowerPC) BuildID: 2000081721 Netscape 6pr2 on mac crashes with SW8.5 when going from a streaming netlanski .dcr to another .dcr (Not in SW8.0) Reproducible: Always Steps to Reproduce: 1.install SW8.5beta into NS6pr2 or mozillaM17 on mac8.6 3.goto http://thebox/netlanski 4. play faces under cast feature 5. while "faces" is downloading click on mudballdcr Actual Results: crash into macsbug Expected Results: no crash this crash does not seem to appear in SW8.0, the released version of shockwave.
Adding shockwave keyword.
Keywords: shockwave
Does this happen in an M18 build?
From Meredith Tomlin (mtomlin@macromedia.com) - On 10/5/00 Kelly Connuingham tested this with Netscape 6pr2 and found thaton mac crashes with SW8.5 when going from a streaming netlanski .dcr to another .dcr (Not in SW8.0) and there are crashes in SW8 and on WIN!
From Meredith Tomlin (mtomlin@macromedia.com) - On 10/5/00 Kelly Cunningham tested this with Netscape 6pr2 and found that on mac NS crashes with SW8.5 when going from a streaming netlanski .dcr to another .dcr (Not in SW8.0) and there are crashes in SW8 and on WIN.
If this bug doesn't happen with SW8.0 but does happen with SW8.5, doesn't that suggest that it's a regression in SW from 8.0 to 8.5 that's causing the browser to crash? Could you modify SW 8.5 in some way so it doesn't trigger this crash? Putting on rtm radar until we figure out what the story is.
Keywords: crash, rtm
cc'd some plugin and mac folks to see if anyone can confirm.
Severity: normal → critical
Priority: P3 → P1
reassign: Peter. I don't think we have the SW 8.5 for mac to test this. All I got was the SW8.5 for windows.
Assignee: av → peterl
I'm pretty sure this is a dup of bug 57189 (Qucktime reload while loading) but I couldn't reproduce that crash yeterday. Will try this today and if I can reproduce this, I'll mark the other as a dup. I'll also double check the talkback stack traces for this and Quicktime to verify dupage. Meredith/Kelly, I don't think we have Shockwave 8.5 for the Mac. Would it be possible to send us a copy of this beta software? A DEBUG build with symbols would probably be very helpfull in fixing crashers. I also recall that Peter Grandmasion said there were some specific issues loading another shockwave movie while one was playing on your end of the SW 8.5. Is this still happening? Shrir, I'm confused about the platform/version in this bug. Could you test SW 8.0 on Mac and Windows and post a stack trace if you have some time? Thanks.
Peter has been added to the Director 8.5 Beta list so he now has access to the latest Win and Mac builds. Please let us know if there is anything else we can do to help track down this issue.
I don't see this crash on windows branch build (plugin: SW8.0 and SW8.5), mac branch build(plugin: SW8.0). Am yet to try SW8.5 on mac. Will comment soon.
I installed SW8.5 on mac (beta 3). On mac branch build 2000101908 ,out of 6-7 attempts, I could crash only once..toggling between the two movies mentioned here (faces and mudball). Pls note that this is not happening at all with other movies. Switching between movies is just working fine. Stack Trace for the crash: Call Stack: (Signature = 0x61aa61a8 bce868a9) 0x61aa61a8 DPLib + 0xbfea4 (0x16ae6a54) PluginLib + 0x9690 (0x1721df40) PluginLib + 0x389c (0x1721814c) ns4xPluginStreamListener::OnStopBinding() [ns4xPluginInstance.cpp, line 336] nsPluginStreamListenerPeer::OnStopRequest() [nsPluginHostImpl.cpp, line 1298] nsHTTPFinalListener::OnStopRequest() [nsHTTPResponseListener.cpp, line 1157] nsHTTPChannel::ResponseCompleted() [nsHTTPChannel.cpp, line 1912] nsHTTPCacheListener::OnStopRequest() [nsHTTPResponseListener.cpp, line 155] nsDiskCacheRecordChannel::OnStopRequest() [nsDiskCacheRecordChannel.cpp, line 709] nsOnStopRequestEvent::HandleEvent() [nsAsyncStreamListener.cpp, line 301] nsStreamListenerEvent::HandlePLEvent() [nsAsyncStreamListener.cpp, line 97] PL_HandleEvent() [plevent.c, line 580] PL_ProcessPendingEvents() [plevent.c, line 513] nsEventQueueImpl::ProcessPendingEvents() [nsEventQueue.cpp, line 356] nsMacNSPREventQueueHandler::ProcessPLEventQueue() [nsToolkit.cpp, line 134] nsMacNSPREventQueueHandler::RepeatAction() [nsToolkit.cpp, line 99] Repeater::DoRepeaters() [nsRepeater.cpp, line 119] nsMacMessagePump::DispatchEvent() [nsMacMessagePump.cpp, line 424] nsMacMessagePump::DoMessagePump() [nsMacMessagePump.cpp, line 253] nsAppShell::Run() [nsAppShell.cpp, line 110]
Hahahah!!!! This is funny and hard to believe and debug. Shrirang, I'm not able to reproduce bug 57189 which I think is the same as this one, except with the quicktime plugin, but you are able to reproduce 100% of the time. However, I am able to reproduce this bug with SW 8.0 100% of the time and you are not. I haven't even tried SW 8.5 yet. Your stack trace below also looks completely different than the ones I've been getting. Accepting bug...
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
I think the MacsBugs stack trace is pointing to something in netwerk. CC:ing gagan for his input.
Even after I install shockwave plugin from home.netscape.com, every time I visit the faces page it will show me a dialog box say "Welcome to Shockwave!" in the title and "You're getting the FREE shockwave Player. With Shockwave Player you can experience engaging, interactive content on the ousands of Web sites!" "Next>" a button If I click the button, then the dialogbox is still there and nothing happne.
I will also see the following from the stderr window About to call CallNPP_SetWindowPropc().... Falling out of ns4xPluginInstance::SetWindow()... created stream for http://pinger.macromedia.com/ killing stream for http://pinger.macromedia.com/
I cannot reach that state that I can reproduce the crash bug. I think our plugging code is not good enough to reach there.
I can install it now. I figure out the plug in download is not working. I install it by the follwing way 1. use Netscape4 to download the shockwave plugin from home.netscape.com 2. use Netscape4 to visit http://poppy.macromedia.com/netlanski and click the facesrc 3. it will show me the same free shockwave download dialog box 4. I click next , it will ask me more question (in Netscape6, it do nothing after I click next, but that is a sperate issue) 5. eventually, it will download and install the shockwave plugin and I can see those shockwave movie on my Netsape4 6. quite Netscape4 7. copy every thing in my netscape4 plugins directory to my Netscap6 plugins directory 8. use Netscape6 to visit that url, now it will show me the shockwave movie playing. I won't crash as kcunningham origional described. I switch between these two movies but it does not crash. And then I click several BACK, it crash and I got the same stack trace as shrirang khanzode 2000-10-19 16:04 trace.
I can now reproduce a different crash by swtich between these two movies. I have to switch from facesrc to mudballdcr before facesrc finish loading and swtich back before mudballdcr finish loading. The stack is different from what I saw last time . Here is the stack trace Calling chain using A6/R1 links Back chain ISA Caller 00000000 PPC 2F0BCC44 18C7EA80 PPC 2F0A2AB4 main+001AC 18C7EA20 PPC 2F0A0440 main1(int, char**, nsISupports*)+0086C 18C7E7B0 PPC 2E7D1E4C nsAppShellService::Run()+00054 18C7E760 PPC 2DDE60C4 nsAppShell::Run()+0004C 18C7E720 PPC 2DDE69B8 nsMacMessagePump::DoMessagePump()+00044 18C7E6D0 PPC 2DDE71F4 nsMacMessagePump::DispatchEvent(int, EventRecord*)+ 001B0 18C7E680 PPC 2DE071CC Repeater::DoRepeaters(const EventRecord&)+0003C 18C7E630 PPC 2DDB31DC nsMacNSPREventQueueHandler::RepeatAction(const EventRecord&)+000 14 18C7E5F0 PPC 2DDB3488 nsMacNSPREventQueueHandler::ProcessPLEventQueue()+ 00244 18C7E550 PPC 2E1DD244 nsEventQueueImpl::ProcessPendingEvents()+00068 18C7E4E0 PPC 2E25EAEC PL_ProcessPendingEvents+000AC 18C7E490 PPC 2E25ED40 PL_HandleEvent+00054 18C7E450 PPC 2D82ED34 nsStreamListenerEvent::HandlePLEvent(PLEvent*)+00050 18C7E410 PPC 2D83099C nsOnDataAvailableEvent::HandleEvent()+000E8 18C7E3C0 PPC 2D8F3564 nsHTTPServerListener::OnDataAvailable(nsIChannel*, nsISupports*, nsIInputStream*, unsigned int, unsigned int)+01388 18C7E160 PPC 2D87FB48 InterceptStreamListener::OnDataAvailable(nsIChannel* , nsISupport s*, nsIInputStream*, unsigned int, unsigned int)+0011C 18C7E0F0 PPC 2D8F5938 nsHTTPFinalListener::OnDataAvailable(nsIChannel*, nsISupports*, nsIInputStream*, unsigned int, unsigned int)+00108 18C7E090 PPC 2D15B598 nsPluginStreamListenerPeer::OnDataAvailable(nsIChannel*, nsISupp orts*, nsIInputStream*, unsigned int, unsigned int)+001F8 18C7DFF0 PPC 2D151F70 ns4xPluginStreamListener::OnDataAvailable(nsIPluginStreamInfo*, nsIInputStream*, unsigned int)+00118 18C7DF80 PPC 2D7E604C Java_ShockwavePlugin_ScriptResult_stub+023BC 18C7DF40 PPC 2D7EB5DC Java_ShockwavePlugin_ScriptResult_stub+0794C 18C7DF00 PPC 2D654FCC mmpCallStreamClient+00124 18C7DE90 PPC 18793BF8 DllGetClassInfo+01E50 18C7DE30 PPC 187936D4 DllGetClassInfo+0192C Closing log
The stack trace looks different every time for me. I'm thinking this may be a problem with memory being destructed and the plugin is still trying to reference that. I'm going to investigate this today. Any other ideas would be helpful.
cc gordon, since the log shows that the crash is in his domain.
Attached patch patch to prevent crash (deleted) — Splinter Review
The crash is happening deep in Macromedia's plugin. The problem is that we should not be calling into the plugin if the plugin has been unloaded (such as in a reload or navigate back/forward). The above patch fixes this crash by basically checking to make sure the plugin is "started" before attempting to the WriteReady call into the plugin. Adding [seeking review] to status whiteboard
Whiteboard: [seeking review]
If this fixes the problem, I think we should take it for rtm. But I am thinking of incorporating this check into that SAFE_CALL macro, since it is probably needed for almost all plugin calls.
I'm afraid of doing this check for all plugin calls because: 1) We set mStarted when Start() and Stop() are called. Using this check before all calls to the plugin would mean carefully tracking the state of mStarted. I'm not sure of the validity of the mStarted flag at all times. 2) The SAFE macros are also used for all calls to plugins including Init and Destory. There may be other plugin methods which we want to skip the check for. 3) We use different indentifiers for the plugin instance in the classes which use the SAFE macros. Checking for this flag would either require a change in the macro's signature or renaming all the indentifiers. 4) Sounds like a big change for RTM and I don't think PDT would take it. I think adding checkes for the plugin state to the SAFE macros is a good idea for 6.01 as long as there is time for testing. Also, Patrick Beard says he has some sample code on handleing hardware exceptions on the Mac which could also be a long-term solution. But, looking at the code again, I think we should be doing this check in OnFileAvailable() so I will attached patch #2 which does this. If this is good with you, I was wondering if I could get module owner approval?
Comments on the patch: if (started) NS_SOME_RANDOM_MACRO is dangerous, because you don't know if the macro expands with {}. Use this instead: if (started) { NS_SOME_RANDOM_MACRO } That's in 2 places.
I am still seeing crashes in 20000101908. While "bigstream" movie is streaming, click on "faces" or "dates". I see crashes on shockwave.com as well but I'm not sure which movies are streaming on shockwave.com.
Adding [rtm need info].
Whiteboard: [seeking review] → [rtm need info] r=av
Adding sr=buster Changing [rtm need info] to [rtm+] to trigger PDT consideration
Whiteboard: [rtm need info] r=av → [rtm+] [r=av sr=buster]
This bug is in candidate limbo. We will reconsider this fix once we have a candidate in hand, but we can't take this fix before then.
This patch was checked into the trunk on Friday.
PDT marking [rtm++]. This bug is now out of limbo and approved for checkin to the branch. Please check in ASAP.
Whiteboard: [rtm+] [r=av sr=buster] → [rtm++] [r=av sr=buster]
Patch checked into the branch. This should work now. Marking FIXED.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
plugin:SW 8.5. Looks good on the mac branch build 2000-10-31-14-MN6. Browser does not crash and movies play fine. Adding keyword:vtrunk to get verified on the trunk. Kelly, it would be great if you could verify this fix.Thanks!
Keywords: vtrunk
I verified this on the trunk (20001116). Looking good.
Status: RESOLVED → VERIFIED
Keywords: vtrunk
Attachment #9194051 - Attachment description: Screenshot_2020-12-19 Screenshot.png → We failed to find a good error description, so do the next best thing was since it might not be part of the stringified error.
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: