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)

x86
Windows NT
defect

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
Reporter: can you attach a stack trace?
 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
Shrirang, was this related to your Real installation problems? Can you try 
again? Does this happen on Mac as well?
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..
Shrir: Any chance you can find out what's special about Suresh's NT?  Different 
versions of Real?  Java enabled/disabled?  Java installed?
let me check...
Depends on: 76936
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
Safe thing to do. r=av
Looks much better! sr=attinasi
Okay, I checked the safer patch in.
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. 
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?
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]


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. :-(..
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.
i manually copied the xpcom real player plugin files in 0430 components folder 
on my NT and it still refuses to recognize it... 
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.
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");
}

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.
Patches to bug 76936 were checked into the trunk and branch. Although I doubt 
that it fixes this bug, please re-test.
(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]

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 .
oh, nononono !! I DID crash after closing the plugin window itself using 0503 
trunk and latest realplayer xpcom bits. Pls ognore my earlier comment .
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.
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.
Keywords: crash
Priority: -- → P1
Whiteboard: [Crash on ReloadPlugins()]
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.
Marking FIXED. This no longer should happen with the patch to bug 79872.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
don't see a crash anymore. Logged seperate bugs for other problems seen. 
Verified (0530 trunk)!
Status: RESOLVED → VERIFIED
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: