From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1a+) Gecko/20020621 BuildID: 2002062109 Browser crashes after rendering some portion of http://www.geocities.com/bobsledding2000/bobbypix2002.html I happened upon this page at random housing listing on craigslist.org. After restarting and revisiting, crash reproduced. Reproducible: Always Steps to Reproduce: 1. Visit http://www.geocities.com/bobsledding2000/bobbypix2002.html 2. 3. Actual Results: crash, feedback agent.

This page, although ugly, works fine in IE and in NN 4.x.

Confirmed, 2002-06-21-04 on Windows 98 SE. TB7600559M

Comment on attachment 88774 [details] Testcase that will crash Mozilla Hmm, testcase did not crash when loaded over HTTP.

It crashes on (attachment 88775 [details]): <embed hidden=TRUE></embed> But not on (attachment 88774 [details]): <embed hidden=true></embed> Crash is always in GKPLUGIN.DLL

For * found plugin D:\moz_source\gmake\mozilla\win32_de\dist\bin\plugins\npnul32 .dll ###!!! ASSERTION: Plugin performed illegal operation: 'PR_FALSE', file d:/moz_so urce/gmake/mozilla/modules/plugin/base/src/nsPluginHostImpl.cpp, line 6162 nsPluginInstancePeerImpl::GetOwner(nsIPluginInstanceOwner * & 0x00000000) line 842 + 6 bytes nsPluginHostImpl::HandleBadPlugin(nsPluginHostImpl * const 0x0108263c, PRLibrary * 0x01082ed8, nsIPluginInstance * 0x04463020) line 6173 + 61 bytes ns4xPluginInstance::InitializePlugin(nsIPluginInstancePeer * 0x0444ff30) line 778 + 276 bytes ns4xPluginInstance::Initialize(ns4xPluginInstance * const 0x04463020, nsIPluginInstancePeer * 0x0444ff30) line 630 nsPluginHostImpl::SetUpDefaultPluginInstance(const char * 0x0012fb14, nsIURI * 0x043d1098, nsIPluginInstanceOwner * 0x043db820) line 4097 + 21 bytes nsPluginHostImpl::InstantiateEmbededPlugin(nsPluginHostImpl * const 0x0108263c, const char * 0x0012fb14, nsIURI * 0x043d1098, nsIPluginInstanceOwner * 0x043db820) line 3502 + 23 bytes nsPluginStreamListenerPeer::OnStartRequest(nsPluginStreamListenerPeer * const 0x043d1010, nsIRequest * 0x043d1378, nsISupports * 0x00000000) line 2063 + 47 bytes nsHttpChannel::ProcessNormal() line 625 + 60 bytes nsHttpChannel::ProcessResponse() line 527 + 8 bytes nsHttpChannel::OnStartRequest(nsHttpChannel * const 0x043d137c, nsIRequest * 0x043f58dc, nsISupports * 0x00000000) line 2824 + 11 bytes nsOnStartRequestEvent::HandleEvent() line 161 + 53 bytes nsARequestObserverEvent::HandlePLEvent(PLEvent * 0x04454acc) line 116 PL_HandleEvent(PLEvent * 0x04454acc) line 596 + 10 bytes PL_ProcessPendingEvents(PLEventQueue * 0x00ff7600) line 526 + 9 bytes _md_EventReceiverProc(HWND__ * 0x011e0110, unsigned int 49407, unsigned int 0, long 16741888) line 1077 + 9 bytes USER32! 77e01b60() USER32! 77e01cca() USER32! 77e083f1() nsAppShellService::Run(nsAppShellService * const 0x0159b400) line 458 main1(int 2, char * * 0x00283160, nsISupports * 0x00000000) line 1456 + 32 bytes main(int 2, char * * 0x00283160) line 1805 + 37 bytes mainCRTStartup() line 338 + 17 bytes KERNEL32! 77e7d326()

no crash (WFM) on Mozilla 1.0, Solaris SPARC.

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

hm..I can't seem to reproduce in either debug or release branch builds. I did open bug 153920 about problems with the OBJECT tag and embedded documents.

Probably is not the bug of mozilla, it is the bug of plugin used. Using npaudio.dll works fine. Could some one show an about:plugins page, where mozilla crashed?

Still crashes, 2002-06-24-08 trunk win98: TB7668345X

Adding topcrash+ and regression keywords, this is a topcrasher with recent MozillaTrunk builds. It appears to be some kind of regression, starting with builds from 6/17. Anyone know of a checkin on 6/17 that might have caused this crash?

on my plate, the patch is folowing

Comment on attachment 88970 [details] My "About Plug-ins" um...no..this is a dynamic page, p/lease copy/paste!

Comment on attachment 88970 [details] My "About Plug-ins" um...no..this is a dynamic page, please copy/paste!

after NS_IMETHODIMP ns4xPluginInstance::GetPeer(nsIPluginInstancePeer* *resultingPeer) { *resultingPeer = mPeer; NS_IF_ADDREF(*resultingPeer); return NS_OK; } call out param should be checked on null.

why bother checking succeeded if it always returns NS_OK?

just in case if ns4xPluginInstance::GetPeer() will be changed in the future

Also, it may return garbage in case of failure.

Comment on attachment 88987 [details] [diff] [review] patch v1 r=av

ccing Patrick for possible sr=

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

Comment on attachment 88987 [details] [diff] [review] patch v1 sr=beard

on the trunk mozilla/modules/plugin/base/src/nsPluginHostImpl.cpp,v <-- nsPluginHostImpl.cpp new revision: 1.396; previous revision: 1.395 Thanks all. Nominating for the branch.

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

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

shrir - can you pls verify that this no longer crashes with the testcases? thanks!

Verified on 0626 trunk build.Checked out all testcases and dups as well. Could only verify on NT..looks good to me. Reporter and others who saw this crash, if possible, could u pls double check and confirm again on the platforms that this is fixed for u as well ? I am sure, it is...Thx!

Works fine for me too, 2002-06-26-08 on Windows 98 SE.

verify working for win95 with 2002062608

verified working with testcase #2, dup 154416 on Win2K. build 2002062608.

adding adt1.0.1+. Please get drivers approval and check into the branch.

please checkin to the 1.0.1 branch. once there, remove the "mozilla1.0.1+" keyword and add the "fixed1.0.1" keyword.

on the branch mozilla/modules/plugin/base/src/nsPluginHostImpl.cpp,v <-- nsPluginHostImpl.cpp new revision: 1.372.2.20; previous revision: 1.372.2.19

verif 0723 brnch, no crash.