Closed
Bug 77319
Opened 24 years ago
Closed 24 years ago
browser crashes when I closed plugin and browser windows in that order
Categories
(Core Graveyard :: Plug-ins, defect, P1)
Tracking
(Not tracked)
VERIFIED
FIXED
mozilla0.9.1
People
(Reporter: shrir, Assigned: peterlubczynski-bugs)
References
()
Details
(Keywords: crash, Whiteboard: [Crash on ReloadPlugins()])
Attachments
(1 file)
windows trunk 0424: steps: due to bug 77302, no realplayer is listed in about:plugins I went to nba.com and clicked on " ISDN+ " in "Top Story" A window came up (with puzzle icon) I clicked "x" on that window to close it and clicked 'x' on the browser window to close it Browser crashed
Assignee | ||
Comment 1•24 years ago
|
||
Reporter: can you attach a stack trace?
Reporter | ||
Comment 2•24 years ago
|
||
Call Stack: (Signature = nsPluginInstanceOwner::~nsPluginInstanceOwner 734f42f3) nsPluginInstanceOwner::~nsPluginInstanceOwner [d:\builds\seamonkey\mozilla\layout\html\base\src\nsObjectFrame.cpp, line 1509] nsPluginInstanceOwner::Release [d:\builds\seamonkey\mozilla\layout\html\base\src\nsObjectFrame.cpp] nsObjectFrame::~nsObjectFrame [d:\builds\seamonkey\mozilla\layout\html\base\src\nsObjectFrame.cpp, line 268] nsObjectFrame::`scalar deleting destructor' nsFrame::Destroy [d:\builds\seamonkey\mozilla\layout\html\base\src\nsFrame.cpp, line 432] gklayout.dll + 0xa9c3c (0x603a9c3c) nsPluginInstanceOwner::AddRef [d:\builds\seamonkey\mozilla\layout\html\base\src\nsObjectFrame.cpp, line 1582
Assignee | ||
Comment 3•24 years ago
|
||
Shrirang, was this related to your Real installation problems? Can you try again? Does this happen on Mac as well?
Reporter | ||
Comment 4•24 years ago
|
||
actually this does not happen on my NT, but on Suresh's nt( cc'ing him). The installation problem that I was having is osmething different. But this bug is from not my machine, so different. need tocheck on mac ( i donot see the xpcom plugin on mac). Will comment soon..
Comment 5•24 years ago
|
||
Shrir: Any chance you can find out what's special about Suresh's NT? Different versions of Real? Java enabled/disabled? Java installed?
Reporter | ||
Comment 6•24 years ago
|
||
let me check...
Assignee | ||
Comment 7•24 years ago
|
||
I'm not getting the stack trace you mention in the bug but I am getting a different crash, probably caused by the same problem. The crash points to callbacks pointing off to space and we try to dereference it. My guess is that the callbacks pointer is bad because we shut down the plugin first. In any case, I've moved up the IsStarted flag check to the top of the methods which should be safer. However, it does not solve the root problem.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.1
Assignee | ||
Comment 8•24 years ago
|
||
Comment 10•24 years ago
|
||
Looks much better! sr=attinasi
Assignee | ||
Comment 11•24 years ago
|
||
Okay, I checked the safer patch in.
Comment 12•24 years ago
|
||
I duplicated this bug using todays build on Win NT. I'm not sure what's the status of this bug (it's still in 'Assigned' state but Peter's last comment says he checked in a patch). This time I used a different site. http://sports.yahoo.com/nba/ and click on 'Video Highlights' link. As soon as the pop-up window comes up it crashes :( Stack trace from talkbalk shows the same as shrir reported on 2001-04-24 10:43. (talkback id: 29831331). And fyi: I did a recommended install.
Assignee | ||
Comment 13•24 years ago
|
||
Wow, completely different stack this time. Suresh, is this the same stack as the one in your talkback? Sorry I can't look it up, cyclone is slow. nsPluginInstanceOwner::GetInstance(nsPluginInstanceOwner * const 0x054adf40, nsIPluginInstance * & 0x062f7700) line 1847 + 15 bytes nsObjectFrame::GetPluginInstance(nsObjectFrame * const 0x054f75b0, nsIPluginInstance * & 0x062f7700) line 1484 nsGenericHTMLElement::GetPluginInstance(nsIPluginInstance * * 0x0012dd20) line 4113 nsGenericHTMLElement::GetPluginScriptObject(nsIScriptContext * 0x054bd1f8, void * * 0x0012dd80) line 4148 + 35 bytes nsHTMLEmbedElement::GetScriptObject(nsHTMLEmbedElement * const 0x054fc234, nsIScriptContext * 0x054bd1f8, void * * 0x0012dd80) line 236 nsHTMLDocument::NamedItem(nsHTMLDocument * const 0x05386264, JSContext * 0x054bd260, long * 0x0012dde8, unsigned int 1, long * 0x0012ddd4) line 3577 + 31 bytes nsHTMLDocument::Resolve(JSContext * 0x054bd260, JSObject * 0x0544b668, long 88388716, int * 0x0012de24) line 3657 + 36 bytes nsJSUtils::nsGenericResolve(JSContext * 0x054bd260, JSObject * 0x0544b668, long 88388716, JSPropertySpec * 0x00000000) line 619 + 38 bytes ResolveHTMLDocument(JSContext * 0x054bd260, JSObject * 0x0544b668, long 88388716) line 687 + 19 bytes _js_LookupProperty(JSContext * 0x054bd260, JSObject * 0x0544b668, long 89137304, JSObject * * 0x0012dfec, JSProperty * * 0x0012dfe0, const char * 0x00f22e10, unsigned int 2182) line 2046 + 24 bytes js_GetProperty(JSContext * 0x054bd260, JSObject * 0x0544b668, long 89137304, long * 0x0012eb58) line 2182 + 35 bytes js_Interpret(JSContext * 0x054bd260, long * 0x0012ed84) line 2540 + 1998 bytes js_Execute(JSContext * 0x054bd260, JSObject * 0x0544a528, JSScript * 0x0550d680, JSStackFrame * 0x00000000, unsigned int 0, long * 0x0012ed84) line 992 + 13 bytes JS_EvaluateUCScriptForPrincipals(JSContext * 0x054bd260, JSObject * 0x0544a528, JSPrincipals * 0x054b6e20, const unsigned short * 0x054bbff8, unsigned int 1751, const char * 0x0550b730, unsigned int 33, long * 0x0012ed84) line 3287 + 25 bytes nsJSContext::EvaluateString(nsJSContext * const 0x054bd1f8, const nsAString & {...}, void * 0x0544a528, nsIPrincipal * 0x054b6e1c, const char * 0x0550b730, unsigned int 33, const char * 0x00f075f0, nsAString & {...}, int * 0x0012ede0) line 609 + 85 bytes HTMLContentSink::EvaluateScript(const nsAString & {...}, nsIURI * 0x054280c8, int 33, const char * 0x00f075f0) line 4582 HTMLContentSink::ProcessSCRIPTTag(const nsIParserNode & {...}) line 4948 HTMLContentSink::AddLeaf(HTMLContentSink * const 0x05489cd8, const nsIParserNode & {...}) line 3193 + 12 bytes CNavDTD::AddLeaf(const nsIParserNode * 0x054de3d0) line 3760 + 22 bytes CNavDTD::HandleScriptToken(const nsIParserNode * 0x054de3d0) line 2247 + 12 bytes CNavDTD::OpenContainer(const nsCParserNode * 0x054de3d0, nsHTMLTag eHTMLTag_script, int 1, nsEntryStack * 0x00000000) line 3414 + 12 bytes CNavDTD::HandleDefaultStartToken(CToken * 0x054e09b8, nsHTMLTag eHTMLTag_script, nsCParserNode * 0x054de3d0) line 1326 + 20 bytes CNavDTD::HandleStartToken(CToken * 0x054e09b8) line 1735 + 22 bytes CNavDTD::HandleToken(CNavDTD * const 0x054de188, CToken * 0x00000000, nsIParser * 0x0384e848) line 899 + 12 bytes CNavDTD::BuildModel(CNavDTD * const 0x054de188, nsIParser * 0x0384e848, nsITokenizer * 0x054d8cf8, nsITokenObserver * 0x00000000, nsIContentSink * 0x05489cd8) line 548 + 20 bytes nsParser::BuildModel() line 1979 + 34 bytes nsParser::ResumeParse(int 1, int 1) line 1860 + 11 bytes nsParser::ContinueParsing() line 1528 + 17 bytes HTMLContentSink::OnStreamComplete(HTMLContentSink * const 0x05489cdc, nsIStreamLoader * 0x054fefa0, nsISupports * 0x00000000, unsigned int 0, unsigned int 234, const char * 0x054bb598) line 4731 + 17 bytes nsStreamLoader::OnStopRequest(nsStreamLoader * const 0x054fefa4, nsIRequest * 0x054fe510, nsISupports * 0x00000000, unsigned int 0) line 120 + 81 bytes nsHTTPFinalListener::OnStopRequest(nsHTTPFinalListener * const 0x054ff0c0, nsIRequest * 0x054fe510, nsISupports * 0x00000000, unsigned int 0) line 1137 + 38 bytes nsStreamListenerTee::OnStopRequest(nsStreamListenerTee * const 0x054bb110, nsIRequest * 0x054fe510, nsISupports * 0x00000000, unsigned int 0) line 25 nsHTTPChunkConv::OnStopRequest(nsHTTPChunkConv * const 0x05517040, nsIRequest * 0x054fe510, nsISupports * 0x00000000, unsigned int 0) line 109 nsHTTPChannel::ResponseCompleted(nsIStreamListener * 0x05517040, unsigned int 0) line 2348 + 32 bytes nsHTTPServerListener::OnStopRequest(nsHTTPServerListener * const 0x054b6b40, nsIRequest * 0x054b6900, nsISupports * 0x054fe510, unsigned int 0) line 709 nsOnStopRequestEvent::HandleEvent() line 159 nsARequestObserverEvent::HandlePLEvent(PLEvent * 0x054b124c) line 64 PL_HandleEvent(PLEvent * 0x054b124c) line 588 + 10 bytes PL_ProcessPendingEvents(PLEventQueue * 0x00c3ab00) line 518 + 9 bytes _md_EventReceiverProc(HWND__ * 0x00120352, unsigned int 49404, unsigned int 0, long 12823296) line 1069 + 9 bytes USER32! 77e148dc() USER32! 77e14aa7() USER32! 77e266fd() nsAppShellService::Run(nsAppShellService * const 0x00bfecb0) line 408 main1(int 1, char * * 0x00357a90, nsISupports * 0x00000000) line 1005 + 32 bytes main(int 1, char * * 0x00357a90) line 1300 + 37 bytes mainCRTStartup() line 338 + 17 bytes KERNEL32! 77e992a6() The crash happens on NS_ADDREF(mInstance) and taking a look at that interface pointer shows it's vtable to be invalid so no wonder it crashes. What is going on with this member variable on this page. Sean/Av how does this relate to bug 76936? Do you think this is a different problem because it the crash comes from script or part of the same instance lifetime problems we have in the other bug? Would it be possible to get a simplified testcase?
Comment 14•24 years ago
|
||
Peter, How did you get the above stack trace? (OR you see the crash that I mentioned?) :) Here is the stack trace I got. nsPluginInstanceOwner::~nsPluginInstanceOwner [d:\builds\seamonkey\mozilla\layout\html\base\src\nsObjectFrame.cpp, line 1520] nsPluginInstanceOwner::Release [d:\builds\seamonkey\mozilla\layout\html\base\src\nsObjectFrame.cpp] nsObjectFrame::~nsObjectFrame [d:\builds\seamonkey\mozilla\layout\html\base\src\nsObjectFrame.cpp, line 267] nsObjectFrame::`scalar deleting destructor' [d:\builds\seamonkey\mozilla\layout\html\base\src\nsFrame.cpp, line 432] gklayout.dll + 0xa9cb4 (0x603b9cb4) nsPluginInstanceOwner::AddRef [d:\builds\seamonkey\mozilla\layout\html\base\src\nsObjectFrame.cpp, line 1593]
Reporter | ||
Comment 15•24 years ago
|
||
well, I checked suresh's machine. The only thing that I found on his box was that 'about:plugins' was showing the 4.x g2 plugin instead of the 6.x xocom plugin . bug 77303 is open for that issue. java installed/not installed did not make any change. :-(..
Assignee | ||
Comment 16•24 years ago
|
||
I think the 4.x Real plugin has problems with 6.x, be sure you have the XPCOM one. I just crashed in my debugger with a pull from last week. I will attempt to update my tree.
Reporter | ||
Comment 17•24 years ago
|
||
i manually copied the xpcom real player plugin files in 0430 components folder on my NT and it still refuses to recognize it...
Comment 18•24 years ago
|
||
The call stack that Suresh has looks the same as the one in bug 76936. No idea what's happening in Peter's crash. I haven't updated in a few days, but when I open the video highlights at http://sports.yahoo.com/nba, I get an endless stream of loadgroup and key assertions. The real player gets built and destroyed between each set of assertions. Definitely something whacked there. Mozilla does generally support the 4x real player (unscripted). Went to another site and experienced no problems.
Comment 19•24 years ago
|
||
The page has this js - it might be the cause of plugin construction, destruction loop that I'm experiencing: if (navigator.appName == "Netscape") { // Refresh plugins navigator.plugins.refresh(true); // Install Applet document.write("\x3C" + "applet MAYSCRIPT codebase=\"/classes\""); document.write(" code=\"com.yahoo.streaming.real.callback\" width=0 height=0"); document.writeln(" name=\"callback.java\"\x3E \x3C/applet\x3E"); }
Comment 20•24 years ago
|
||
Looks like this could be due to the greater issue over at 76936. When navigator.plugins.refresh(true) is called, nsPluginHostImpl::ReloadPlugins() stops and calls nsIPluginIinstance->Destroy on all the active plugin instances. That means that outstanding references probably become invalid. Peter, in nsPluginHostImpl::ReloadPlugins change the: if(reloadPages) to if(0) and see if that fixes your crash.
Assignee | ||
Comment 21•24 years ago
|
||
Patches to bug 76936 were checked into the trunk and branch. Although I doubt that it fixes this bug, please re-test.
Comment 22•24 years ago
|
||
(Assuming that the patches should have been in today's build: 2001050304) I still see the same problem. This time I tried to close the realplayer window launched from news.com. I did a recommended install. But Stack trace from talkback shows different place in code where it crashes. nsMenuPopupFrame::KillCloseTimer [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsMenuPopupFrame.cpp, line 1516] BasicTableLayoutStrategy::ReduceOverSpecifiedPctCols [d:\builds\seamonkey\mozilla\layout\html\table\src\BasicTableLayoutStrategy.cpp, line 1139] nsOutlinerBodyFrame::GetItemWithinCellAt [d:\builds\seamonkey\mozilla\layout\xul\base\src\outliner\src\nsOutlinerBodyFrame.cpp, line 812] nsObjectFrame::InstantiatePlugin [d:\builds\seamonkey\mozilla\layout\html\base\src\nsObjectFrame.cpp, line 1020] nsCSSFrameConstructor::ConstructFrameByTag [d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSFrameConstructor.cpp, line 4803] gklayout.dll + 0xaacb4 (0x603cacb4) nsSplitterFrameInner::MouseDrag [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsSplitterFrame.cpp, line 579]
Reporter | ||
Comment 23•24 years ago
|
||
don't see the crash on 0503 build using the new real xpcom bits (not yet in the tree) on windows. I need to test these bits on suresh's box and resolve this bug if it does not crash .
Reporter | ||
Comment 24•24 years ago
|
||
oh, nononono !! I DID crash after closing the plugin window itself using 0503 trunk and latest realplayer xpcom bits. Pls ognore my earlier comment .
Assignee | ||
Comment 25•24 years ago
|
||
There are many stack traces and reasons for crashing in this bug. Can we see if we can narrow it down to what is the the simplest testcase needed to reproduce the same crash. Is this Real only on NT or others too? Otherwise, I feel like grasping at straws trying to fix this and it looks serious.
Assignee | ||
Comment 26•24 years ago
|
||
Okay, let's split this appart. Rephrasing what I think the problem is in the status whiteboard. For bugs about the crash in nsPluginInstanceOwner::~nsPluginInstanceOwner, see if you have Java installed. If so, go to bug 76936 as that's probably it. If not, make comments here. I see how one can crash in ReloadPlugins. Leave this bug open on that issue. The fix to bug 76936 will likley fix this too.
Comment 27•24 years ago
|
||
shrir saw this bug today (closing a plugin window crashes) using todays build. Unfortunately the talkback data doesn't provide any symbols :( (Incident id: 30325203). btw, when I clicked on the '230k' link it open up a BLANK window. That issue is now covered in bug 80375.
Assignee | ||
Comment 28•24 years ago
|
||
Marking FIXED. This no longer should happen with the patch to bug 79872.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 29•24 years ago
|
||
don't see a crash anymore. Logged seperate bugs for other problems seen. Verified (0530 trunk)!
Status: RESOLVED → VERIFIED
Updated•2 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•