FF10PR1 Crash with any javascript popup window (window.open) [@ 0x00000000 - nsCOMPtr_base::assign_with_AddRef ]

RESOLVED WORKSFORME

Status

()

Firefox
General
--
critical
RESOLVED WORKSFORME
14 years ago
a year ago

People

(Reporter: Alex, Assigned: dbaron)

Tracking

(4 keywords)

Trunk
crash, fixed-aviary1.0, fixed1.7.5, topcrash+
Points:
---
Bug Flags:
blocking-aviary1.0 +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [patch][useful comments: 46-47, 63, 67, 75-77, 94], crash signature)

Attachments

(6 attachments, 6 obsolete attachments)

105 bytes, text/html
Details
2.98 KB, text/plain
Details
29.75 KB, text/plain; charset=us-ascii
Details
660 bytes, application/vnd.mozilla.xul+xml
Details
451 bytes, application/vnd.mozilla.xul+xml
Details
11.59 KB, patch
Darin Fisher
: superreview+
Details | Diff | Splinter Review
(Reporter)

Description

14 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040803 Firefox/0.8
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040803 Firefox/0.8

When I'm looking web pages and some popup needs to come up, the firefox crashes
(all windows opened of course).

I've blocked up the popup windows with the Preferences and now I can "live", but
I would like to have them on...

It's a bud in 0.9.3
0.9 hasn't this problem

Maybe it's just in pages when the window.open javascript function tries to open
the window at the beginning... The window.open function works perfectly when the
page is loaded completely. So it's a window.open problem while the loading of
the body.

Reproducible: Always
Steps to Reproduce:
1. Go to any popup window web page
2. 
3.

Comment 1

14 years ago
Alex: Could you provide TalkBack incident ID of your crash?
Keywords: crash
(Reporter)

Comment 2

14 years ago
(In reply to comment #1)
> Alex: Could you provide TalkBack incident ID of your crash?

Of course... here you got some of 'em

TB544347Y, TB543949H, TB543792W, TB539006X, TB539000E, TB538996E, TB538993X,
TB536882M, TB536455Z, TB536329W, TB533012G, TB533008Z, TB532904E, TB525359W,
TB516082Q, TB516081X, TB513618Z, TB513605W

Comment 3

14 years ago
Most of incidents has this stacktrace:
0x00000000
nsCOMPtr_base::assign_with_AddRef 
[d:/builds/tinderbox/firefox-0.9.3/WINNT_5.0_Clobber/mozilla/xpcom/glue/nsCOMPtr.cpp,
line 90]
nsImageBoxFrame::DidSetStyleContext 
[d:/builds/tinderbox/firefox-0.9.3/WINNT_5.0_Clobber/mozilla/layout/xul/base/src/nsImageBoxFrame.cpp,
line 558]
nsIFrame::SetStyleContext  [../../../../dist/include/layout/nsIFrame.h, line 577]
nsFrameManager::ReResolveStyleContext 
[d:/builds/tinderbox/firefox-0.9.3/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsFrameManager.cpp,
line 1616]
nsFrameManager::ComputeStyleChangeFor 
[d:/builds/tinderbox/firefox-0.9.3/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsFrameManager.cpp,
line 1659]
nsCSSFrameConstructor::AttributeChanged 
[d:/builds/tinderbox/firefox-0.9.3/WINNT_5.0_Clobber/mozilla/layout/html/style/src/nsCSSFrameConstructor.cpp,
line 10088]
PresShell::AttributeChanged 
[d:/builds/tinderbox/firefox-0.9.3/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsPresShell.cpp,
line 5202]
nsXULElement::SetAttrAndNotify 
[d:/builds/tinderbox/firefox-0.9.3/WINNT_5.0_Clobber/mozilla/content/xul/content/src/nsXULElement.cpp,
line 2225]
nsXULElement::SetAttr 
[d:/builds/tinderbox/firefox-0.9.3/WINNT_5.0_Clobber/mozilla/content/xul/content/src/nsXULElement.cpp,
line 2148]
nsXULElement::SetAttribute 
[d:/builds/tinderbox/firefox-0.9.3/WINNT_5.0_Clobber/mozilla/content/xul/content/src/nsXULElement.cpp,
line 1022]
XPTC_InvokeByIndex 
[d:/builds/tinderbox/firefox-0.9.3/WINNT_5.0_Clobber/mozilla/xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp,
line 102]
XPCWrappedNative::CallMethod 
[d:/builds/tinderbox/firefox-0.9.3/WINNT_5.0_Clobber/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp,
line 2027]
XPC_WN_CallMethod 
[d:/builds/tinderbox/firefox-0.9.3/WINNT_5.0_Clobber/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp,
line 1287]
js_Invoke 
[d:/builds/tinderbox/firefox-0.9.3/WINNT_5.0_Clobber/mozilla/js/src/jsinterp.c,
line 941]
js_Interpret 
[d:/builds/tinderbox/firefox-0.9.3/WINNT_5.0_Clobber/mozilla/js/src/jsinterp.c,
line 2973]
js_Invoke 
[d:/builds/tinderbox/firefox-0.9.3/WINNT_5.0_Clobber/mozilla/js/src/jsinterp.c,
line 958]
nsXPCWrappedJSClass::CallMethod 
[d:/builds/tinderbox/firefox-0.9.3/WINNT_5.0_Clobber/mozilla/js/src/xpconnect/src/xpcwrappedjsclass.cpp,
line 1336]
nsXPCWrappedJS::CallMethod 
[d:/builds/tinderbox/firefox-0.9.3/WINNT_5.0_Clobber/mozilla/js/src/xpconnect/src/xpcwrappedjs.cpp,
line 450]
SharedStub 
[d:/builds/tinderbox/firefox-0.9.3/WINNT_5.0_Clobber/mozilla/xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp,
line 147]
nsEventListenerManager::HandleEventSubType 
[d:/builds/tinderbox/firefox-0.9.3/WINNT_5.0_Clobber/mozilla/content/events/src/nsEventListenerManager.cpp,
line 1434]
nsEventListenerManager::HandleEvent 
[d:/builds/tinderbox/firefox-0.9.3/WINNT_5.0_Clobber/mozilla/content/events/src/nsEventListenerManager.cpp,
line 1512]
GlobalWindowImpl::HandleDOMEvent 
[d:/builds/tinderbox/firefox-0.9.3/WINNT_5.0_Clobber/mozilla/dom/src/base/nsGlobalWindow.cpp,
line 892]
nsXULDocument::HandleDOMEvent 
[d:/builds/tinderbox/firefox-0.9.3/WINNT_5.0_Clobber/mozilla/content/xul/document/src/nsXULDocument.cpp,
line 1257]
nsXULElement::HandleDOMEvent 
[d:/builds/tinderbox/firefox-0.9.3/WINNT_5.0_Clobber/mozilla/content/xul/content/src/nsXULElement.cpp,
line 2823]
nsXULElement::HandleDOMEvent 
[d:/builds/tinderbox/firefox-0.9.3/WINNT_5.0_Clobber/mozilla/content/xul/content/src/nsXULElement.cpp,
line 2821]
nsXULElement::HandleDOMEvent 
[d:/builds/tinderbox/firefox-0.9.3/WINNT_5.0_Clobber/mozilla/content/xul/content/src/nsXULElement.cpp,
line 2821]
nsXULElement::HandleDOMEvent 
[d:/builds/tinderbox/firefox-0.9.3/WINNT_5.0_Clobber/mozilla/content/xul/content/src/nsXULElement.cpp,
line 2821]
nsXULElement::HandleDOMEvent 
[d:/builds/tinderbox/firefox-0.9.3/WINNT_5.0_Clobber/mozilla/content/xul/content/src/nsXULElement.cpp,
line 2821]
nsXULElement::HandleDOMEvent 
[d:/builds/tinderbox/firefox-0.9.3/WINNT_5.0_Clobber/mozilla/content/xul/content/src/nsXULElement.cpp,
line 2821]
nsXULElement::HandleDOMEvent 
[d:/builds/tinderbox/firefox-0.9.3/WINNT_5.0_Clobber/mozilla/content/xul/content/src/nsXULElement.cpp,
line 2821]
nsXULElement::HandleChromeEvent 
[d:/builds/tinderbox/firefox-0.9.3/WINNT_5.0_Clobber/mozilla/content/xul/content/src/nsXULElement.cpp,
line 3984]
GlobalWindowImpl::HandleDOMEvent 
[d:/builds/tinderbox/firefox-0.9.3/WINNT_5.0_Clobber/mozilla/dom/src/base/nsGlobalWindow.cpp,
line 888]
DocumentViewerImpl::LoadComplete 
[d:/builds/tinderbox/firefox-0.9.3/WINNT_5.0_Clobber/mozilla/content/base/src/nsDocumentViewer.cpp,
line 913]
nsDocShell::EndPageLoad 
[d:/builds/tinderbox/firefox-0.9.3/WINNT_5.0_Clobber/mozilla/docshell/base/nsDocShell.cpp,
line 4330]
nsWebShell::EndPageLoad 
[d:/builds/tinderbox/firefox-0.9.3/WINNT_5.0_Clobber/mozilla/docshell/base/nsWebShell.cpp,
line 805]
nsDocShell::OnStateChange 
[d:/builds/tinderbox/firefox-0.9.3/WINNT_5.0_Clobber/mozilla/docshell/base/nsDocShell.cpp,
line 4264]
nsDocLoaderImpl::FireOnStateChange 
[d:/builds/tinderbox/firefox-0.9.3/WINNT_5.0_Clobber/mozilla/uriloader/base/nsDocLoader.cpp,
line 1232]
nsDocLoaderImpl::doStopDocumentLoad 
[d:/builds/tinderbox/firefox-0.9.3/WINNT_5.0_Clobber/mozilla/uriloader/base/nsDocLoader.cpp,
line 867]
nsDocLoaderImpl::OnStopRequest 
[d:/builds/tinderbox/firefox-0.9.3/WINNT_5.0_Clobber/mozilla/uriloader/base/nsDocLoader.cpp,
line 695]
nsLoadGroup::RemoveRequest 
[d:/builds/tinderbox/firefox-0.9.3/WINNT_5.0_Clobber/mozilla/netwerk/base/src/nsLoadGroup.cpp,
line 695]
nsInputStreamChannel::OnStopRequest 
[d:/builds/tinderbox/firefox-0.9.3/WINNT_5.0_Clobber/mozilla/netwerk/base/src/nsInputStreamChannel.cpp,
line 371]
nsInputStreamChannel::`vftable'
nsPrintOptions::AddRef 
[d:/builds/tinderbox/firefox-0.9.3/WINNT_5.0_Clobber/mozilla/gfx/src/nsPrintOptionsImpl.cpp,
line 69]
0x8b560c45

other signatures/stacks:
http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=TB539006X
http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=TB536455Z
http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=TB536329W
http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=TB525359W
http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=TB516081X
http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=TB513618Z
Summary: Crash with any popup window → Crash with any popup window [@ 0x00000000 - nsCOMPtr_base::assign_with_AddRef ]
(Reporter)

Comment 4

14 years ago
And what does they mean ?
i do not know nothing about that

Comment 5

14 years ago
Alex: stacktrace should be usefull for developers, it provides links to
problematic part of source code.
(Reporter)

Comment 6

14 years ago
Ok, i didn't know exactly the working of this.
Then i supposed i cann't do anything but wait :)

I just wanted to paste you this erro because i think it's critical

Thank you and i wait for resolution of this
(Reporter)

Comment 7

14 years ago
I have downgrade to 0.9
and now there's no problem at all

But i'd like to use the latest stable one :)

Comment 8

14 years ago
This is clearly the #1 crasher with early Talkback data for Firefox 1.0 PR1. 
Here are a couple of sets of crashes:

Count   Offset    Real Signature
[ 16   0x00000000 26066259 - nsCOMPtr_base::assign_with_AddRef ]
 
     Crash date range: 14-SEP-04 to 15-SEP-04
     Min/Max Seconds since last crash: 26 - 17482
     Min/Max Runtime: 1012 - 22473
 
     Count   Platform List 
     16   Windows XP [Windows NT 5.1 build 2600] 
 
     Count   Build Id List 
     16   2004091322
 
     No of Unique Users        13
 
 Stack trace(Frame) 

	 0x00000000  
	 nsCOMPtr_base::assign_with_AddRef
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/xpcom/glue/nsCOMPtr.cpp
 line 90] 
	 nsImageBoxFrame::UpdateAttributes
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/layout/xul/base/src/nsImageBoxFrame.cpp
 line 372] 
	 nsCSSFrameConstructor::AttributeChanged
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/layout/html/style/src/nsCSSFrameConstructor.cpp
 line 10114] 
	 PresShell::AttributeChanged
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/layout/html/base/src/nsPresShell.cpp
 line 5192] 
	 nsXULElement::SetAttrAndNotify
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/content/xul/content/src/nsXULElement.cpp
 line 2225] 
	 nsXULElement::SetAttr
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/content/xul/content/src/nsXULElement.cpp
 line 2148] 
	 nsXBLPrototypeBinding::AttributeChanged
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/content/xbl/src/nsXBLPrototypeBinding.cpp
 line 483] 
	 nsXBLBinding::AttributeChanged
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/content/xbl/src/nsXBLBinding.cpp
 line 842] 
	 nsXULElement::SetAttrAndNotify
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/content/xul/content/src/nsXULElement.cpp
 line 2193] 
	 nsXULElement::SetAttr
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/content/xul/content/src/nsXULElement.cpp
 line 2148] 
	 nsXBLPrototypeBinding::AttributeChanged
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/content/xbl/src/nsXBLPrototypeBinding.cpp
 line 483] 
	 nsXBLBinding::AttributeChanged
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/content/xbl/src/nsXBLBinding.cpp
 line 842] 
	 nsXULElement::SetAttrAndNotify
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/content/xul/content/src/nsXULElement.cpp
 line 2193] 
	 nsXULElement::SetAttr
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/content/xul/content/src/nsXULElement.cpp
 line 2148] 
	 nsXULElement::SetAttribute
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/content/xul/content/src/nsXULElement.cpp
 line 1022] 
	 XPTC_InvokeByIndex
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp
 line 102] 
	 XPCWrappedNative::CallMethod
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp
 line 2028] 
	 XPC_WN_CallMethod
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp
 line 1287] 
	 js_Invoke
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/js/src/jsinterp.c 
line 941] 
	 js_Interpret
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/js/src/jsinterp.c 
line 2973] 
	 js_Invoke
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/js/src/jsinterp.c 
line 958] 
	 js_InternalInvoke
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/js/src/jsinterp.c 
line 1035] 
	 js_InternalGetOrSet
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/js/src/jsinterp.c 
line 1078] 
	 js_SetProperty
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/js/src/jsobj.c  line
2849] 
	 js_Interpret
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/js/src/jsinterp.c 
line 2164] 
	 js_Invoke
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/js/src/jsinterp.c 
line 958] 
	 js_InternalInvoke
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/js/src/jsinterp.c 
line 1035] 
	 JS_CallFunctionValue
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/js/src/jsapi.c  line
3698] 
	 nsJSContext::CallEventHandler
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/dom/src/base/nsJSEnvironment.cpp
 line 1297] 
	 GlobalWindowImpl::RunTimeout
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/dom/src/base/nsGlobalWindow.cpp
 line 5083] 
	 GlobalWindowImpl::TimerCallback
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/dom/src/base/nsGlobalWindow.cpp
 line 5445] 
	 nsXULWindow::CreateNewContentWindow
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/xpfe/appshell/src/nsXULWindow.cpp
 line 1832] 
	 nsXULWindow::CreateNewWindow
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/xpfe/appshell/src/nsXULWindow.cpp
 line 1716] 
	 nsWindowCreator::CreateChromeWindow2
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/toolkit/xre/nsWindowCreator.cpp
 line 123] 
	 nsWindowWatcher::OpenWindowJS
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/embedding/components/windowwatcher/src/nsWindowWatcher.cpp
 line 620] 
	 nsWindowWatcher::OpenWindow
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/embedding/components/windowwatcher/src/nsWindowWatcher.cpp
 line 458] 
	 GlobalWindowImpl::OpenInternal
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/dom/src/base/nsGlobalWindow.cpp
 line 4682] 
	 GlobalWindowImpl::Open
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/dom/src/base/nsGlobalWindow.cpp
 line 3280] 
	 XPTC_InvokeByIndex
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp
 line 102] 
	 XPCWrappedNative::CallMethod
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp
 line 2028] 
	 XPC_WN_CallMethod
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp
 line 1287] 
	 js_Invoke
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/js/src/jsinterp.c 
line 941] 
	 js_Interpret
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/js/src/jsinterp.c 
line 2973] 
	 js_Execute
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/js/src/jsinterp.c 
line 1162] 
	 JS_EvaluateUCScriptForPrincipals
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/js/src/jsapi.c  line
3649] 
	 nsJSContext::EvaluateString
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/dom/src/base/nsJSEnvironment.cpp
 line 946] 
	 nsJSThunk::EvaluateScript
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/dom/src/jsurl/nsJSProtocolHandler.cpp
 line 286] 
	 nsJSChannel::InternalOpen
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/dom/src/jsurl/nsJSProtocolHandler.cpp
 line 533] 
	 nsJSChannel::AsyncOpen
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/dom/src/jsurl/nsJSProtocolHandler.cpp
 line 513] 
	 nsURILoader::OpenURI
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/uriloader/base/nsURILoader.cpp
 line 827] 
	 nsDocShell::DoChannelLoad
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/docshell/base/nsDocShell.cpp
 line 5884] 
	 nsDocShell::DoURILoad
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/docshell/base/nsDocShell.cpp
 line 5663] 
	 nsDocShell::InternalLoad
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/docshell/base/nsDocShell.cpp
 line 5449] 
	 nsWebShell::OnLinkClickSync
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/docshell/base/nsWebShell.cpp
 line 652] 
	 OnLinkClickEvent::HandleEvent
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/docshell/base/nsWebShell.cpp
 line 438] 
	 PL_HandleEvent
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/xpcom/threads/plevent.c
 line 674] 
	 0x778b0c24  
	 nsFormSubmission::ProcessValue
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/content/html/content/src/nsFormSubmission.cpp
 line 1455] 
	 0x8a370815   
 
     (816853)	URL: http://www.bose.com/learning/project_sound/bose_suspension.jsp
     (811667)	Comments: I clicked on a link within BestBuy.com
 
====================================================================================================
     Count   Offset    Real Signature
[ 15   0x00000000 c61e5ce1 - nsCOMPtr_base::assign_with_AddRef ]
 
     Crash date range: 14-SEP-04 to 15-SEP-04
     Min/Max Seconds since last crash: 99 - 29463
     Min/Max Runtime: 100 - 29463
 
     Count   Platform List 
     13   Windows XP [Windows NT 5.1 build 2600] 
     2   Windows 2K [Windows NT 5.0 build 2195] 
 
     Count   Build Id List 
     15   2004091322
 
     No of Unique Users        15
 
 Stack trace(Frame) 

	 0x00000000  
	 nsCOMPtr_base::assign_with_AddRef
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/xpcom/glue/nsCOMPtr.cpp
 line 90] 
	 nsImageBoxFrame::UpdateAttributes
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/layout/xul/base/src/nsImageBoxFrame.cpp
 line 372] 
	 nsCSSFrameConstructor::AttributeChanged
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/layout/html/style/src/nsCSSFrameConstructor.cpp
 line 10114] 
	 PresShell::AttributeChanged
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/layout/html/base/src/nsPresShell.cpp
 line 5192] 
	 nsXULElement::SetAttrAndNotify
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/content/xul/content/src/nsXULElement.cpp
 line 2225] 
	 nsXULElement::SetAttr
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/content/xul/content/src/nsXULElement.cpp
 line 2148] 
	 nsXBLPrototypeBinding::AttributeChanged
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/content/xbl/src/nsXBLPrototypeBinding.cpp
 line 483] 
	 nsXBLBinding::AttributeChanged
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/content/xbl/src/nsXBLBinding.cpp
 line 842] 
	 nsXULElement::SetAttrAndNotify
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/content/xul/content/src/nsXULElement.cpp
 line 2193] 
	 nsXULElement::SetAttr
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/content/xul/content/src/nsXULElement.cpp
 line 2148] 
	 nsXBLPrototypeBinding::AttributeChanged
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/content/xbl/src/nsXBLPrototypeBinding.cpp
 line 483] 
	 nsXBLBinding::AttributeChanged
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/content/xbl/src/nsXBLBinding.cpp
 line 842] 
	 nsXULElement::SetAttrAndNotify
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/content/xul/content/src/nsXULElement.cpp
 line 2193] 
	 nsXULElement::SetAttr
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/content/xul/content/src/nsXULElement.cpp
 line 2148] 
	 nsXULElement::SetAttribute
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/content/xul/content/src/nsXULElement.cpp
 line 1022] 
	 XPTC_InvokeByIndex
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp
 line 102] 
	 XPCWrappedNative::CallMethod
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp
 line 2028] 
	 XPC_WN_CallMethod
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp
 line 1287] 
	 js_Invoke
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/js/src/jsinterp.c 
line 941] 
	 js_Interpret
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/js/src/jsinterp.c 
line 2973] 
	 js_Invoke
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/js/src/jsinterp.c 
line 958] 
	 js_InternalInvoke
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/js/src/jsinterp.c 
line 1035] 
	 js_InternalGetOrSet
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/js/src/jsinterp.c 
line 1078] 
	 js_SetProperty
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/js/src/jsobj.c  line
2849] 
	 js_Interpret
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/js/src/jsinterp.c 
line 2164] 
	 js_Invoke
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/js/src/jsinterp.c 
line 958] 
	 js_InternalInvoke
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/js/src/jsinterp.c 
line 1035] 
	 JS_CallFunctionValue
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/js/src/jsapi.c  line
3698] 
	 nsJSContext::CallEventHandler
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/dom/src/base/nsJSEnvironment.cpp
 line 1297] 
	 GlobalWindowImpl::RunTimeout
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/dom/src/base/nsGlobalWindow.cpp
 line 5083] 
	 GlobalWindowImpl::TimerCallback
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/dom/src/base/nsGlobalWindow.cpp
 line 5445] 
	 nsXULWindow::CreateNewContentWindow
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/xpfe/appshell/src/nsXULWindow.cpp
 line 1832] 
	 nsXULWindow::CreateNewWindow
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/xpfe/appshell/src/nsXULWindow.cpp
 line 1716] 
	 nsWindowCreator::CreateChromeWindow2
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/toolkit/xre/nsWindowCreator.cpp
 line 123] 
	 nsWindowWatcher::OpenWindowJS
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/embedding/components/windowwatcher/src/nsWindowWatcher.cpp
 line 620] 
	 nsWindowWatcher::OpenWindow
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/embedding/components/windowwatcher/src/nsWindowWatcher.cpp
 line 458] 
	 GlobalWindowImpl::OpenInternal
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/dom/src/base/nsGlobalWindow.cpp
 line 4682] 
	 GlobalWindowImpl::Open
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/dom/src/base/nsGlobalWindow.cpp
 line 3280] 
	 XPTC_InvokeByIndex
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp
 line 102] 
	 XPCWrappedNative::CallMethod
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp
 line 2028] 
	 XPC_WN_CallMethod
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp
 line 1287] 
	 js_Invoke
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/js/src/jsinterp.c 
line 941] 
	 js_Interpret
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/js/src/jsinterp.c 
line 2973] 
	 js_Invoke
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/js/src/jsinterp.c 
line 958] 
	 js_InternalInvoke
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/js/src/jsinterp.c 
line 1035] 
	 JS_CallFunctionValue
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/js/src/jsapi.c  line
3698] 
	 nsJSContext::CallEventHandler
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/dom/src/base/nsJSEnvironment.cpp
 line 1297] 
	 nsJSEventListener::HandleEvent
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/dom/src/events/nsJSEventListener.cpp
 line 184] 
	 nsEventListenerManager::HandleEventSubType
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/content/events/src/nsEventListenerManager.cpp
 line 1436] 
	 nsEventListenerManager::HandleEvent
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/content/events/src/nsEventListenerManager.cpp
 line 1516] 
	 nsGenericElement::HandleDOMEvent
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/content/base/src/nsGenericElement.cpp
 line 1960] 
	 nsGenericHTMLElement::HandleDOMEventForAnchors
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/content/html/content/src/nsGenericHTMLElement.cpp
 line 1365] 
	 nsHTMLAnchorElement::HandleDOMEvent
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/content/html/content/src/nsHTMLAnchorElement.cpp
 line 326] 
	 nsGenericElement::HandleDOMEvent
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/content/base/src/nsGenericElement.cpp
 line 1990] 
	 nsHTMLImageElement::HandleDOMEvent
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/content/html/content/src/nsHTMLImageElement.cpp
 line 579] 
	 PresShell::HandleEventInternal
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/layout/html/base/src/nsPresShell.cpp
 line 6057] 
	 PresShell::HandleEventWithTarget
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/layout/html/base/src/nsPresShell.cpp
 line 5982] 
	 nsEventStateManager::CheckForAndDispatchClick
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/content/events/src/nsEventStateManager.cpp
 line 2921] 
	 nsEventStateManager::PostHandleEvent
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/content/events/src/nsEventStateManager.cpp
 line 1921] 
	 PresShell::HandleEventInternal
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/layout/html/base/src/nsPresShell.cpp
 line 6109] 
	 PresShell::HandleEvent
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/layout/html/base/src/nsPresShell.cpp
 line 5919] 
	 nsViewManager::HandleEvent
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/view/src/nsViewManager.cpp
 line 2290] 
	 nsViewManager::DispatchEvent
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/view/src/nsViewManager.cpp
 line 2030]  
 
     (819005)	URL:
http://www.bilsport.se/artikel_bild_topp.php3?visa_id=48731&bildnamn=top_02_produktnytt.gif&avdelning=11#
     (819005)	Comments: I was about to click on a picture to enlarge it. Then
Firefox just shut down.
     (817309)	Comments: Looking at wincustomize.com at the wallpaper section
     (816614)	URL: wincustomize.com
     (815246)	URL: www.customize.com
     (813535)	URL: www.pentax.com
     (813232)	URL:
http://www.vsen.tv/gallery3/folderview.asp?bid=2&folder=WCG+2004+Brasil

Since the real stack signature is beneath 0x00000000, this crash will be
difficult to query for.  Just go to:

http://talkback-public.mozilla.org/reports/firefox/FF10PR1/smart-analysis.all

And search for nsCOMPtr_base::assign_with_AddRef for more stack info and user
comments.  Marking topcrash+ and nominating for aviary1.0 to get this on the
radar early.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking-aviary1.0?
Keywords: topcrash+
Summary: Crash with any popup window [@ 0x00000000 - nsCOMPtr_base::assign_with_AddRef ] → FF10PR1 Crash with any popup window [@ 0x00000000 - nsCOMPtr_base::assign_with_AddRef ]

Comment 9

14 years ago
Not sure if it belongs in this bug or not, but I've experienced three crashes so
far with 1.0PR on Linux, all related to launching a popup window. All from
http://www.pgdp.net/c/tools/proofers/proof_per.php (needs login), using
javascript onclick: on links to open a new window. Popup blocking is enabled; no
sites added to allow list.

TB IDs are TB817272Y, TB831321Q, TB831599W.
Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20040914 Firefox/0.10
Mandrake 9.2: Kernel 2.4.22 / XFree86 v4.3 / WindowMaker v0.80.2

I have not yet been able to reliably reproduct this crash.
I've not been able to reproduce this using any of the URLs given in talkback
reports or using my own testcases with window.open.  Some sort of timing
problem, maybe...

Comment 11

14 years ago
(In reply to comment #10)
> I've not been able to reproduce this using any of the URLs given in talkback
> reports or using my own testcases with window.open.  Some sort of timing
> problem, maybe...

See bug 259822. I think it's the same error, and I can always reproduce it.

Comment 12

14 years ago
(In reply to comment #11)
> (In reply to comment #10)
> > I've not been able to reproduce this using any of the URLs given in talkback
> > reports or using my own testcases with window.open.  Some sort of timing
> > problem, maybe...
> 
> See bug 259822. I think it's the same error, and I can always reproduce it.

All the url's in this bug (and bug 259822) give me a stacktrace like in bug
258943 (crashes in nsImageBoxFrame::AttributeChanged). I'm using Firefox 1.0PR
on Mac OS X. The stacktraces in this bug look different (crashes in
nsCOMPtr_base::assign_with_AddRef), but that seems to be related to the
platform. I alwasy crashed at the same location.

Should we dupe these 2 (bug 258943 and bug 259822) to this one, and mark it for
all platforms ?

Comment 13

14 years ago
*** Bug 259822 has been marked as a duplicate of this bug. ***

Comment 14

14 years ago
jst and dbaron can you have a look at this?  we want to try and get this for 1.0
Assignee: firefox → jst
Flags: blocking-aviary1.0? → blocking-aviary1.0+
OS: Windows XP → All
Hardware: PC → All
*** Bug 258943 has been marked as a duplicate of this bug. ***
Summary: FF10PR1 Crash with any popup window [@ 0x00000000 - nsCOMPtr_base::assign_with_AddRef ] → FF10PR1 Crash with any javascript popup window (window.open) [@ 0x00000000 - nsCOMPtr_base::assign_with_AddRef ]
Version: unspecified → 1.0 Branch

Comment 16

14 years ago
(In reply to comment #14)
> jst and dbaron can you have a look at this?  we want to try and get this for 1.0

See bug 258943 comment 31 :

This crash might have accidently been solved a few days ago. Maybe the fairies
did it ?
This happens to me consistently on OS X (Mozilla/5.0 (Macintosh; U; PPC Mac OS X
Mach-O; rv:1.7.3) Gecko/20040913 Firefox/0.10) for any window.open() which
specifies a "width" in the feature-set parameter. I do not get crashes when
width is not specified.

Comment 18

14 years ago
still repro (semi-random, but often enough to make it unusable...) on:

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040930 Firefox/0.10
StumbleUpon/1.998

Comment 19

14 years ago
Uri:  Any chance you can put together a quick testcase that crashes and attach
it to this bug?  I've been having trouble reproducing this with the various urls
I've found in Talkback data. 
Created attachment 160808 [details]
testcase for crashing Ff/0.10 on OS X

Click on the words "Click Me!" to crash Firefox
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; rv:1.7.3) Gecko/20040913
Firefox/0.10
This is 100% reproducable for me.

Comment 21

14 years ago
(In reply to comment #20)
> Created an attachment (id=160808)
> testcase for crashing Ff/0.10 on OS X
> 
> Click on the words "Click Me!" to crash Firefox
> Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; rv:1.7.3) Gecko/20040913
> Firefox/0.10
> This is 100% reproducable for me.

Though I'm annoyed by this bug too (I had a crash with this build a little while
ago), I couldn't 100% reproduce it on your testcase. In my case it happens
sometimes, but not always with the same links.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041001
Firefox/0.10

Comment 22

14 years ago
(In reply to comment #21) 
> Though I'm annoyed by this bug too (I had a crash with this build a little while
> ago), I couldn't 100% reproduce it on your testcase. In my case it happens
> sometimes, but not always with the same links.
> 
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041001
> Firefox/0.10

I had the same problem with Firefox/0.10 on GNU/Linux, it would crash randomly,
on sites, and if I viewed the site/page later, it'd work perfectly.

But, Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20041001 Firefox/0.10.1
doesn't seem to crash anymore. I just upgraded today, so I will try it out for a
bit to make sure this bug is really gone.

Comment 23

14 years ago
How to reproduce:

recipe derived on: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3)
Gecko/20041002 Firefox/0.10 StumbleUpon/1.998

Background: a few times people have pointed the finger at sessionsaver (among
other possibilities for plugin trouble).  I am pretty sure that the trouble is
not with sessionsaver, but with the number of tabs that are open.  It may be
either just more likely with many tabs, or caused by many tabs.

Steps:

(clean install, clean profile [sic!])

1. Bookmarks -> Firefox Crew Picks -> Open in tabs
2. from the google news page, open up all the headlines in new tabs; repeat
until you have 40+ tabs open [tabs fall off the right edge, and are no longer
all displayed]
3. go to: http://story.news.yahoo.com/news?tmpl=index2&cid=1059  [this should be
the news photo popular slideshows page, from which all the photos are links to
javascript popups]
4. click on any of the js popup photo links

should be near 100% repro

please confirm

Comment 24

14 years ago
(In reply to comment #23)
> Background: a few times people have pointed the finger at sessionsaver (among
> other possibilities for plugin trouble).  I am pretty sure that the trouble is
> not with sessionsaver, but with the number of tabs that are open.  It may be
> either just more likely with many tabs, or caused by many tabs.

I've used no tabs in my browsing and won't use them henceforce, but encounters
this bug.

Comment 25

14 years ago
This problem does not occur on both of my Macintoshes.
One is a G3 iBook, problem occurs.
Other is a G4 500MHz, proble has not occurred yet.
I have not determined any differences as to Firefox or OS versions or system extensions.
Hmmm... the machine I'm seeing this on is a G3 iMac running OS X 10.3 (Panther).
Perhaps this is G3-specific? (would be weird, but weird things happen).

Floyd - on your iBook, is this 100% reproducable (with the testcase I attached)?
So far, I seem to be the only one here who can reproduce this consistently.

Comment 27

14 years ago
(In reply to comment #23)
> Steps:
> 
> (clean install, clean profile [sic!])
> 
> 1. Bookmarks -> Firefox Crew Picks -> Open in tabs
> 2. from the google news page, open up all the headlines in new tabs; repeat
> until you have 40+ tabs open [tabs fall off the right edge, and are no longer
> all displayed]
> 3. go to: http://story.news.yahoo.com/news?tmpl=index2&cid=1059  [this should be
> the news photo popular slideshows page, from which all the photos are links to
> javascript popups]
> 4. click on any of the js popup photo links
> 
> should be near 100% repro
> 
> please confirm

I have noticed that often times when I have this crash it is with no tabs open
whatsoever. Usually its at work, where our intranet app does a popup at body
onLoad and FF crashes instantly. If i restart FF and go to that page again, it
works flawlessly.

Mike, the bug you mention may be related to what I encounter, but I'm not so sure.

Comment 28

14 years ago
In reply to uriber@gmail.com:

  Yes it is 100% reproducible on my G3 iBook using the posted test case
  and every other window.open() example I have tried (they all include
  a width= argument).

  The one exception was when I tried disabling "fast user switching",
  which was one thing different about the settings on my two computers.
  When I first disabled it and tried a wndow.open example, it worked
  and did not crash.  However, it was only that one time.  Subsequent
  attempts caused the crash.  I think this must have been a fluke
  but thought I would mention it.

  Also, I don't think this problem occurred before I upgraded the iBook
  to Panther.  Previously I was running Jaguar (10.2.8).  However, I
  cannot say for sure that I used a javascript window.open() with Firefox
  running under Jaguar.

  So it may be a G3 / OSX 10.3 specific problem.
is this the same with bug I filed: FF10PR1 crashes when I try to open the GMAIL
CONTACTS (it's a pop-up): Bug 262686

Comment 30

14 years ago
(In reply to comment #28)
> In reply to uriber@gmail.com:
>
>   So it may be a G3 / OSX 10.3 specific problem.

It's 100% reproducible on my G3 ibook with 10.2.8, so it's not Panther-specific.
Works for me...
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; rv:1.7.3) Gecko/20041001
Firefox/0.10.1

iBook G3 700 MHz - OS X 10.3.5
Even though I wasn't able to reproduce the crash using this testcase I am still
having crash trouble with other popup window sites.
WFM: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20040914 Firefox/0.10.1
*** Bug 262686 has been marked as a duplicate of this bug. ***

Comment 35

14 years ago
I'll second comment 24; I don't use tabs in browsing (only windows) and have
gotten the popup crash on Linux.

Comment 36

14 years ago
Well, isn't this just fabulous, I am running:

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.3) Gecko/20041003
Firefox/0.10

And up until I installed THIS version, the problem hadn't re-occured. Like I
said in the bug filed before; find out the prick who submitted a patch that
CAUSED this breakage and remove his rights to submit code in future.

Comment 37

14 years ago
Matt, let's try and keep things civil.

Comment 38

14 years ago
Matt, let's try and keep things civil.

Comment 39

14 years ago
Had a crash again with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3)
Gecko/20041004 Firefox/0.10

Comment 40

14 years ago
This still occurs with Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; rv:1.7.3)
Gecko/20041001 Firefox/0.10.1

What tends to happen is that I have it occur sometimes once or twice a day - it
does not happen consistently - but is always triggered by clicking on a link
that pops up a window.  Today's crash was triggered by a phpMyAdmin Query Window
link.

I have the following extensions installed if that helps: Web Developer 0.8,
Gmail Notifier 0.3.3 and SpellBound 0.6.0.

Talkback ID: TB1129052Q

I had, prior to 0.10.1 been using a nightly, I think it was 20040928 or 20040929
which I hadn't managed to crash in the week or so before this new release.

Comment 41

14 years ago
using Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20041001 Firefox/0.10.1

had a crash on window.open on body onLoad. restarted FF and this time it worked
perfectly.

talkback id: TB1136161Q

Comment 42

14 years ago
I have the same problem: the test case didn't work for me, I use tabs a lot, it
seems to only work after a certain uptime of the browser. Re
https://bugzilla.mozilla.org/show_bug.cgi?id=255372#c40 : I don't use any of
your extensions. What I have is Sage, Adblock, Linky, Single window, MiniT and
mouse gestures.

Comment 43

14 years ago
I can reproduce a popup crash 100% of the time.

Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20041006 Firefox/0.10.1

In Gmail, when viewing an email, you are given an option to send a gmail invite
to the sender.  This normally opens a pop-up.  I've tried switching between
compiled and binary installs, with the same effect.

With Firefox 0.10.1 on Windows XP and Windows 2000, I get the popup fine,
without a crash.  However, I have definitely been experiencing many crashes with
.10 and .10.1 on Windows as well, mostly (all?) associated with pop-ups.

Email me at martin@simaltech.com for gmail invites for testing.  Hopefully
someone more skilled that me can use this to construct a test case.
(In reply to comment #32)
> Even though I wasn't able to reproduce the crash using this testcase I am still
> having crash trouble with other popup window sites.

Now I am getting this crash 100% of the time -- same build, different day.

Comment 45

14 years ago
I also see this with 0.10.1 on Linux, but only on 32bit architectures - amd64
doesn't exhibit the bug, but x86 and powerpc both do.
Backtrace comes out to be:
http://www.planetarytramp.net/firefox-bt
Steps to reproduce - this is 100% reproducible with a freshly opened firefox
session, a bit less reliable after the browser has been running for some time:
Open browser. 
Go to gmail (I, too, have invites available if necessary)
Click contacts
Click "Import Contacts"
segfault leading to the above back trace.

I'm happy to debug further if someone wants to point me in the right direction.
(In reply to comment #17)
> This happens to me consistently on OS X (Mozilla/5.0 (Macintosh; U; PPC Mac OS X
> Mach-O; rv:1.7.3) Gecko/20040913 Firefox/0.10) for any window.open() which
> specifies a "width" in the feature-set parameter. I do not get crashes when
> width is not specified.

I was wrong about this. The actual crucial feature is not "width", but
"toolbar". Any window.open() which does not require a toolbar (i.e., specifies a
non-empty feature set, which does not include "toolbar") crashes. If "toolbar"
is specified (or no featureset is specified there is no crash).

Which suggests the following workaround: Set
dom.disable_window_open_feature.toolbar to "true". All windows will open with a
toolbar, and no crashes. This works for me, at least.

I hope this information will somehow be useful in tracking down the source of
this bug.
What I meant to write is:

If "toolbar" is specified (or no featureset is specified) there is no crash.

Sorry for the spam.
(In reply to comment #45)
> I also see this with 0.10.1 on Linux, but only on 32bit architectures - amd64
> doesn't exhibit the bug, but x86 and powerpc both do.
> Backtrace comes out to be:
> http://www.planetarytramp.net/firefox-bt
> Steps to reproduce - this is 100% reproducible with a freshly opened firefox
> session, a bit less reliable after the browser has been running for some time:
> Open browser. 
> Go to gmail (I, too, have invites available if necessary)
> Click contacts
> Click "Import Contacts"
> segfault leading to the above back trace.

I've yet to see this crash myself, and I just tried again to reproduce it
following the above instructions w/o luck, using a build from today on Linux x86.

> I'm happy to debug further if someone wants to point me in the right direction.

Do you have any extensions installed? If so, try a clean install with a clean
profile and let us know, and if you're able to catch this in a debugger, poke
around an see if you see anything odd...

Comment 49

14 years ago
(In reply to comment #30)
> (In reply to comment #28)
> > In reply to uriber@gmail.com:
> >
> >   So it may be a G3 / OSX 10.3 specific problem.
> 
> It's 100% reproducible on my G3 ibook with 10.2.8, so it's not Panther-specific.

It took a few days before it crashed my G4, 400 MHz. But then it crashed 3 times
in a row before I forced the toolbar, so it isn't G3 specific. But it does crash
my two G3s more often. Maybe it's some kind of timing problem, more likely to
crash on a slower computer? (That could explain why more tabs increases the
probability of a crash for some also)

(Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; rv:1.7.3) Gecko/20041001
Firefox/0.10.1)
I spent some time testing this today on a Mac G3 400 MHz Running 10.2.8 as well
as on my own machine G4 867 MHz running 10.3.5 and was not able to reproduce it.
 I tried Uri's attachment on both machines and it did not crash (just spawned a
new window.)  I tested with a clean profile as well as an existing profile.  I
also went back and forth between gmail since that was mentioned as one problem
site but saw no issues.

Can the people on this bug that are still having issues with crashing (especialy
the ones that are experiencing it 100% of the time) provide more information -
such as what extensions/themes are installed, how much RAM they have, specific
sites they were at when it crashed.  This will help us out since we are not able
to currently reproduce it with the data provided. Thanks.

Comment 51

14 years ago
(In reply to comment #50)
> Can the people on this bug that are still having issues with crashing (especialy
> the ones that are experiencing it 100% of the time) provide more information -
> such as what extensions/themes are installed, how much RAM they have, specific
> sites they were at when it crashed.  This will help us out since we are not able
> to currently reproduce it with the data provided. Thanks.

I haven't managed to force it to crash. Sometimes I can use Firefox for days
without a crash, but when it starts crashing, it continues for a while. That is
after the first crash, start up Firefox, click on an popup-link and it crashes
again (about 100% then, which makes it impossible to finish whatever you were
trying to do. Not depending on site). Between that it doesn't crash. I'm not
sure how I've managed to make it stop crashing, I usually return to 0.9.3. Which
site doesn't seem to matter, I think Uri's attachment is as good as any to
reproduce the crash.

I have no extensions/themes installed. New profile except a bookmarkfile, or an
old profile. 160-224MB of RAM, 233-400 MHz G3-G4, Mac OS 10.2.6 or 10.3.5.

Comment 52

14 years ago
I just installed Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US;
rv:1.7.3) Gecko/20041006 Firefox/0.10 on OS X 10.2.8, ibook G3 500MhZ with 384MB
RAM. 
On first try, the testcase crashed FF with both a clean  and an old profile.
After restart, I could open it several times, so I tried to click on the
pictures at http://www.swosh-music.com/content/media_photos_band.php it worked,
but it took quite long before opening the picture in a new window, even giving
me a spinning beachball (usually happened before crashing). Then I wanted to try
to do the same when having opened many tabs. But I didn't even came to click on
a link, because opening about 5 additional tabs crashed FF.
Just tried the same again: testcase, swosh-music.com in new tab, opened pictures
on swosh, opened several new tabs, tried swosh again, tried testcase again. And
everything worked. Then I tried to open the cuneaform extension which always
crashed on me with the 21sept. build, there was the beachball, but the window
was opened. But when I tried to close it, FF crashed. Restarting FF, opening and
closing cuneaform, worked fine.
So it went down from 100% to occasional crashes for me.
Extensions I have installed:

keyconfig
jump link
dictionary search
bugmenot
image-show-hide
linky
openbook
switchproxy tool
tab double-click
cookie button
download manager tweak
user agent switcher
go up (disabled)
digger (disabled)
adblock
cuneaform

I don't have gmail, but if anyone cares to invite me, I'll be more than happy to
test it. :-)

Comment 53

14 years ago
Marcia Knous asked for some specifics.

On iBook 500MHz with 256 MB ram, the crash occurs 100% on the test case.
Also crashes on http://www.wayneart.org/wacschedule.php?db=children when
clicking on one of the class names that is suppoed to open a small window
with a description of the class.

I have no Firfox extensions or additional themes installed, just the default
installation.

The suggeted work-around setting om.disable_window_open_feature.toolbar to
"true" avoid the crash so I'll gep that option set for the time being.

Would it help if you had a copy of crash log or core dump?
I'm not sure I know where those are saved or if some option needs
to be set to save the kinds of details you would need.
The original reporter says this problem occurs with the 0.9.3 release build and
not with the 0.9 release.  It might make sense for someone who can actually
reproduce this issue to:

1.  Verify the above

and

2.  Try the 0.9.1 and 0.9.2 release builds as well?  We may easily be able to
narrow it doewn to a couple of checkins if we can narrow this down a bit more. 
there were not all that many checkins between 0.9 and 0.9.3 in the first place.
> Can the people on this bug that are still having issues with crashing (especialy
> the ones that are experiencing it 100% of the time) provide more information -
> such as what extensions/themes are installed, how much RAM they have, specific
> sites they were at when it crashed.  This will help us out since we are not able
> to currently reproduce it with the data provided. Thanks.

I'm seeing this on a clean, brand new, profile (as well as on my regular profile).
My machine's specs: 350 MHz G3, 384 MB SDRAM, OS X 10.3.5.
Talkback incident IDs (using the atached testcase): TB1158364Y (with the 0.10
release) and TB1156886H (with the 20041006 nightly).
(In reply to comment #54)
> The original reporter says this problem occurs with the 0.9.3 release build and
> not with the 0.9 release.  It might make sense for someone who can actually
> reproduce this issue to:
> 
> 1.  Verify the above
> 

I do not see the crash on 0.9.3. I should also mention that I do not see the
crash on a recent trunk build (20040928). If there's somewhere out there an
archive of nightlies between 0.9 and 0.10, I'll be willing to try out some of
them to help see where the regression occured.
*** Bug 263282 has been marked as a duplicate of this bug. ***
I found the nightly build archives and conducted a binary search. Results:
Branch builds up to and including the 20040906 build do not crash on the testcase.
Branch builds from 20040908 and onwards do crash.

I couldn't get the 20040907 build to work at all: The "Select a Profile" dialog
didn't display any profiles, didn't allow me to create a new one, and didnt let
me continue without selecting a profile.

So we're left with about 48 hours of checkins to search.
Based on the dates in my previous comment, I think the main suspect for this bug
is the patch for bug 252326 (attachment 158155 [details] [diff] [review]). It has to do with
window.open(),a nd it was checked into the Aviary branch on 2004-09-07.
It's a big and complex patch, and it's beyond my abilities to determine how it
is responsible for this crash (if at all). I'll leave a comment on that bug, and
hopefully someone will be able to take it from there.
OK - given that this bug was reported on a 20040803 build, my previous comment
looks a bit stupid.

However, I think this means that we're dealing with more than one bug here. I
think there's a Mac-specific bug which started on 20040908, and which was
originally reported as bug 258943 (on 20040911), and then there's a
non-Mac-specific bug, which started earlier, and was reported here.

I'd recommend re-opening bug 258943 (and setting the Platform/OS back to
Macintosh/OS X). All of my previous comments on this bug (as well as the
testcase), would then apply to that bug.

Apologies for all the spam. I think I'll go find something else to do now...

Comment 61

14 years ago
I backed up /home/marty/.mozilla and restarted Firefox with a fresh profile.

Neither the Gmail Invite, Gmail Contact Import, nor
http://story.news.yahoo.com/news?tmpl=index2&cid=1059 photo-clicking caused a
crash (and these were 100% before).

In my profile, I had the web developper extension, adblock, and a user agent
switcher installed - but these were all removed when I started testing this bug.

(Gentoo Linux x86)

I'm going to try testing after more surfing/tab use, then add my extensions back
one at a time.

Comment 62

14 years ago
Unfortunately I can't reproduce this bug either, neither with Firefox 0.10.1,
nor with my SeaMonkey build (both on Windows XP). Looking at the stacktrace it
doesn't seem too likely that this problem has been caused by bug 252326, but
I'll check it again...
I was finally able to test the 20040907 build (The problem which stopped me from
doing this before was bug 258308. I overcame it by asking Firefox not to ask me
for a profile on startup).

Build 20040907 crashes on the testcase. This rules out my suspicion of bug
252326 (the fix was checked in only after the 20040907 build). Apologies to
Wladimir and everyone.

Now that I know that the regression was between 20040906 and 20040907, I have a
new suspect: bug 22183 (I'm not sure yet which patch was actually checked in at
that date. I think it was attachment 157864 [details] [diff] [review]). The fixes for that bug deal
directly with the toolbar (which is inline with my comment #46). So I hope I'm
not making wrong accusations again.
I suspect bug 22183 as well.  It appears that a bunch of code was checked in
originally when the intent was to enforce the location bar.  When it was decided
to do this by enforcing the statusbar instead most of the location bar change
code was left in, although it should not be necessary.  In particualr I suspect
the code in browser.js which appears to still be in the the branch.
I posted my additional findings, for OS X, in bug 258943 (which was reopened per
my recommendation).
More progress.

I now know that this bug (or at least its root cause) was present in the code at
least since build 20040514 (just before the Aviary branching).
I also know that it was fixed on the trunk between the 20040803 and 20040804 (OS
X) builds.
Given this, I have strong reason to believe that attachment 155070 [details] [diff] [review] to bug 236889
is what fixed the bug on the trunk. 

How I know this (the long story):

Previously I found out that changes made to the chrome on 20040907 were causing
this bug to manifest itself consistently on my machine. I figured out I can
retrofit older builds with the crash-causing chrome to see if it makes them crah
on my testcase. I started by trying this on the 0.9.3 release - and indeed, it
crashed as expected. I also needed to verify that the trunk wasn't crashing. I
injected the "crashy" branch chrome into a recent trunk build - no crash.
Now there were two possibilities - either this regressed on the branch, or was
fixed on the trunk. To test this, I took a pre-brach build (20040515), and
injected the crashy chrome. It crashed.
From here on it was a binary search on the trunk. Seven "download - replace
chrome - test" cycles later, I was able to pin-point the fix to between the
20040803 and 20040804 trunk builds.

I then ran the following bonsai query:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=MozillaTinderboxAll&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2004-08-03+09%3A00%3A00&maxdate=2004-08-04+10%3A00%3A00&cvsroot=%2Fcvsroot
and noticed the 236889 fix, which touched, among other things, nsImageBoxFrame -
the class in which, according to the stack traces, was where this bug is crashing.

Updated

14 years ago
Blocks: 258943
Using the method described above, I was able to reproduce the crash on Firefox
0.8 (20040206) and Firebird 0.7 (20031007). Those versions pretty much choked on
the new chrome, but I still managed somehow to try my testcase and crash.
I couldn't get Firebird 0.6 to run at all (even with the original chrome), so I
left it alone.
Bottom line - if this is a regression, it happened before 20031007. As far is I
can tell, the bug might have been there, dormant, since the dawn of time, only
to be awaken on September 2004 (on OS X, perhaps a bit earlier on Windows) by
some innocent-seeming chrome changes.
It's a strange coincidence that it was apparenty fixed, on the trunk, one day
after the build on which this bug was reported (on the branch).

I need to leave my iMac now for a few of days, so you probably won't be hearing
from me on this bug soon. I'd like to thank everyone who encouraged me to
continue my investigations. I hope my findings will help fixing this bug.

And finally, sorry for using this bug a my personal blog for the last couple of
days :-)

Comment 69

14 years ago
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a5) Gecko/20041010
Firefox/0.9.1+

Flat screen iMac 10.2.8

The test case does not crash on a build from my tree, but I have added many null
pointer checks. 

I have also tried with a modified test case which requests the 'about:' window
(as the test case's pop-ip came up with an empty URL bar - Cmd-U on that page
did describe itself as 'Source of about:blank'), and this also worked, but I 
got these messages in gdb:

JavaScript error: chrome://browser/content/browser.js, line 476: isBidiEnabled
is not defined
WARNING: PresShell::EndLoad(nsIDocument *) RootScrollFrame is not scrollable?,
file ../../../../../src/layout/html/base/src/nsPresShell.cpp, line 3547

Is the problem known or suspected to occur with builds from the HEAD? If not,
I am probably wasting my time and yours.

Comment 70

14 years ago
Created attachment 161667 [details]
Warnings and Assertion failures

This is a list of warnings and assertion failures evinced whilst
trying to reproduce this bug. Since the problem (if it is actually
in) could be in code a year old or so, I can't really rule any of
these out on inspection.
(In reply to comment #69)
> Is the problem known or suspected to occur with builds from the HEAD? If not,
> I am probably wasting my time and yours.

I'm afraid you probably are. Please read the beginning of comment #67.

Comment 72

14 years ago
Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20041001 Firefox/0.10.1

Windows XP

Not using tab browsing.

But problem occurs on a regular basis, not 100% of time though.

Sample HTML i am using to open popup

<a onClick='javascript:window.open("client_class_detail.php?ClassID=<?PHP
echo($classRow["ClassID"]); ?>","","resizable=1,WIDTH=615,HEIGHT=400")'
onMouseOver="window.status='See Class Details'; return true" href='#'><?PHP
echo($classRow["Name"]); ?></a>

Comment 73

14 years ago
After a fews days use, the dom.disable_window_open_feature.toolbar set to true
workaround does prevent prevent firefox from crashing. Thanks for the tip, it
should be made the default while the bug hasn't been fixed.
Talked to dbaron about this one, and he does *not* want to land his fix for bug
236889 on the branch, but he'll have a look and see if there's parts of that
that could be landed, or if he can see what the problem with nsImageBoxFrame
might be here.

Thank you Uri for all your great detective work here! :)
Assignee: jst → dbaron
The three recent Linux talkback reports that I looked at all have the string
file:///usr/lib/firefox/searchplugins/google.gif (in 16-bit characters) on the
stack.
The Linux crashes seem to involve crashing on the following code in
nsImageBoxFrame::UpdateImage:

  // otherwise, we need to load the new uri
  if (mImageRequest) {
    mImageRequest->Cancel(NS_ERROR_FAILURE);
    mImageRequest = nsnull;
  }

The nsImageBoxFrame::UpdateImage is not the top frame on the stack, but the
second from the top.  The current point in that function is the
nsCOMPtr_base::assign_with_AddRef call associated with the |mImageRequest =
nsnull| line.  The top stack frame, however, has led to jumping to some other
location and the crash is due to either SIGSEGV or SIGILL, with the EIP usually
being 0x09??????, an address that's not inside any shared object.
FWIW, the top of the Linux stack I was looking at is:

    	 0x096c798b   	 
    	nsImageBoxFrame::UpdateImage() 
[/builds/tinderbox/firefox-0.10.1/Linux_2.4.20-28.8_Clobber/mozilla/layout/xul/base/src/nsImageBoxFrame.cpp,
line 607]
    	nsImageBoxFrame::AttributeChanged() 
[/builds/tinderbox/firefox-0.10.1/Linux_2.4.20-28.8_Clobber/mozilla/layout/xul/base/src/nsImageBoxFrame.cpp,
line 266]
    	nsCSSFrameConstructor::AttributeChanged() 
[/builds/tinderbox/firefox-0.10.1/Linux_2.4.20-28.8_Clobber/mozilla/layout/html/style/src/nsCSSFrameConstructor.cpp,
line 10114]


Which, like the Windows stacks, has a frame missing, but a different one
(UpdateImage vs. UpdateAttributes)

Comment 78

14 years ago
Still having it on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3)
Gecko/20041016 Firefox/1.0
*** Bug 260032 has been marked as a duplicate of this bug. ***
Whiteboard: [useful comments: 46-47, 67, 75-77]
Whiteboard: [useful comments: 46-47, 67, 75-77] → [useful comments: 46-47, 63, 67, 75-77]
No longer blocks: 264557
*** Bug 264557 has been marked as a duplicate of this bug. ***
(In reply to comment #63)
> Now that I know that the regression was between 20040906 and 20040907, I have a
> new suspect: bug 22183 (I'm not sure yet which patch was actually checked in at
> that date. I think it was attachment 157864 [details] [diff] [review]). The fixes for that bug deal
> directly with the toolbar (which is inline with my comment #46). So I hope I'm
> not making wrong accusations again.

Do you know what the hours of the builds are?  The checkin you suspect is, I
presume, 
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=AVIARY_1_0_20040515_BRANCH&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2004-09-06+16%3A07&maxdate=2004-09-06+16%3A09&cvsroot=%2Fcvsroot

However, based on the stack and on comment 75, I think
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=AVIARY_1_0_20040515_BRANCH&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2004-09-07+07%3A49&maxdate=2004-09-07+07%3A51&cvsroot=%2Fcvsroot
may be a possibility.
You're absolutely right. I created a bit of a mess here. My appologies.

Right after writing comment #67, bug 258943 was re-opened according to my
recommendation (at that point I thought that there was a separate, OS X-specific
bug. I no longer believe that now). So my next findings were posted there, form
bug 258943 comment 36 onwards (don't bother reading everything before comment 40).

In bug 258943 comment 40, I verified that the patch you're pointing to is really
the one that started the crashing.

Specifically, I believe the problem has to do with the drawing of the icons on
the re-designed search bar. Why are these are drawn when the new window is
supposed to have the toolbar hidden, is a mystery to me. 

Comment 83

14 years ago
In my case [Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20041001
Firefox/0.10.1], this happens only after Firefox has eaten up a good amount of
memory.  At that point, (even if I close all tabs any extra FF windows, no
memory is released  -- another bug, IMHO) clicking on any javascript link that
causes popups of the kind that have been mentioned will cause a crash.

Again, above-described crash will not happen for me if Firefox has gobbled up
less than, say, 40 MB.  I've seen others report that this crash happens only
after some time.  For me this crash is directly related to the amount of memory
the process has allocated rather than the length of time it's been running
(although there's usually a positive correlation between running time and memory
allocated, since FF for some reason never free()s any substantial amount of memory).

The string on the stack doesn't necessarily correspond to the attribute in
question -- it doesn't make sense, and it could be in a piece of uninitialized
stack.
(In reply to comment #77)
> Which, like the Windows stacks, has a frame missing, but a different one
> (UpdateImage vs. UpdateAttributes)

The reason the frame is missing is that gcc does tail-call optimization in
nsImageBoxFrame::UpdateAttributes (it frees the stack space before calling
UpdateImage).
And, FWIW, there's nothing corrupt about the Linux stack at all (at least for
incident 1310792).  Talkback is just unable to show the top frame correctly
because the call instruction crashed, so EIP shows the place (not code) that it
called but EBP still points to the beginning of the calling stack frame (since
the caller wasn't real code, or whatever, so it didn't save ESP into EBP yet). 
The stack seems 100% consistent with simply crashing on the Release() call in
nsCOMPtr_base::assign_with_AddRef, called from nsImageBoxFrame::UpdateImage,
called (via tail call optimization) from nsImageBoxFrame::UpdateAttributes,
called from nsImageBoxFrame::AttributeChanged.

FWIW, in that incident, the nsCOMPtr's mRawPtr looks like a real heap address
(0x09502f90), but its vtable pointer (0x0939b271) does not look like a code
address (rather, it looks like a heap address).

This makes the underlying problem seem like either a reference counting bug or a
memory corruption bug.  That it was fixed by bug 236889 makes me suspect the former.

Comment 87

14 years ago
This happens with any popup link on http://www.itsolutions.intuit.com/, such as
the ROI calculator link. 

Comment 88

14 years ago
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; rv:1.7.3) Gecko/20041001
Firefox/0.10.1

This happens with any popup link on http://www.itsolutions.intuit.com/, such as
the ROI calculator link. 

Comment 89

14 years ago
I get this also running FFPR under Xandros Desktop v2.0, I did let the Feedback
report for the first few days but now it's happening too often so I have
disabled the Feedback function.  

Crash with popups seems to be random, I tried it with popups blocked and
permission for one domain and it still crashed when I tried to open a popup on
that domain. I've now turned off popup blocking, allow javascript to raise/lower
windows and it's still causing random crashes on various sites. No set pattern
at all. 

Is there a file I can find on my box and submit to you to help bugfix this?
So, is anybody who's seeing this on a non-Macintosh platform using the default
theme?  If not, what theme are you using?

Comment 91

14 years ago
I'm seeing this on FreeBSD with the default theme, and no extensions loaded.  I
am not alone.  Other users are seeing it as well.  A good FreeBSD trigger is
changing the locale to a value other than en_US.  However, users in the en_US
locale also encounter this crash periodically with no themes or extensions loaded.

One thing's for sure.  The workaround of setting
dom.disable_window_open_feature.toolbar to true works for everyone.

Comment 92

14 years ago
I've just crashed a firefox 0.10.1 20041001 using the method up there (open all
google news headlines, and a yahoo popup), on a clean profile - not even the
linky ext to open the headlines. I'm running linux.
Too bad the QA wasn't activated, I can try & get it if it is useful.
I am able to reproduce the bug on Mac OS X, and the |primaryFrame| object in
nsCSSFrameConstructor::AttributeChanged has all of its member variables marked
as 0xdddddddd but the vtable pointer looks ok.  That seems bizarre.
Created attachment 162773 [details]
stack showing the real problem
So I think the obvious fix here is to set the chromehidden attribute, and
perhaps do all the rest of the work that happens in ApplyChromeFlags, a lot
earlier.  The obvious place that "seems nice" is right after
ApplyPersistentAttributes in nsXULDocument::ResumeWalk.  It would be nice to do
it before StartLayout, I think -- although maybe frames other than the root
aren't constructed before StartLayout and doing it in the document observer's
EndLoad notification would be fine.  I need to figure that out.
Whiteboard: [useful comments: 46-47, 63, 67, 75-77] → [useful comments: 46-47, 63, 67, 75-77, 94]
Created attachment 162806 [details]
simplified testcase for crash
Created attachment 162807 [details]
testcase for crash with alerts
Created attachment 162810 [details] [diff] [review]
low risk patch for branch

This should fix it (I've only tested with the testcase so far, but I'll double
check the Mac build shortly).

I think what's really keeping this fixed on the trunk is style change
coalescing.  I suspect that before that landed my list-style-image patch just
happened to tweak things in a way that Purify would still have objected to, but
that didn't crash -- although I could be wrong about that.  (SHOULD
INVESTIGATE)

I'm not sure whether we really want to depend on style change coalescing to
handle this kind of thing, or whether there's some invariant that we should
really be maintaining on the trunk.  (SHOULD DISCUSS)

I think we definitely *do* want to make the setting of chromehidden and those
other things happen earlier -- but that could be risky, and we can do it on the
trunk.	(SHOULD FILE SEPARATE BUG)
Comment on attachment 162810 [details] [diff] [review]
low risk patch for branch

OK, never mind, this doesn't fix the real crash.  (Perhaps the image is already
loaded?)
Attachment #162810 - Attachment is obsolete: true
(Although it's possible that it could fix some of the crashes we're seeing in
talkback...)
Created attachment 162811 [details]
simplified testcase for crash

This one is a little harder to fix because there's no new request.
Attachment #162806 - Attachment is obsolete: true
Attachment #162811 - Attachment is patch: false
Attachment #162811 - Attachment mime type: text/plain → application/vnd.mozilla.xul+xml

Comment 102

14 years ago
(In reply to comment #97)
> Created an attachment (id=162807)
> testcase for crash with alerts

Are you sure this is the same bug? All new testcases crashes for me even after
setting dom.disable_window_open_feature.toolbar to true, which this bug never
has done before. (Or am I missing some workaround for that fix?)
(In reply to comment #102)
> Are you sure this is the same bug? All new testcases crashes for me even after
> setting dom.disable_window_open_feature.toolbar to true, which this bug never
> has done before. (Or am I missing some workaround for that fix?)

Setting that preference simply makes Firefox's UI stop being a (very
complicated) testcase for the underlying XUL bug.

Comment 104

14 years ago
> So, is anybody who's seeing this on a non-Macintosh platform using the default
theme?  If not, what theme are you using?

Windows 2000, default theme, no extensions here.

Comment 105

14 years ago
https://bugzilla.mozilla.org/attachment.cgi?id=162811&action=view

This link also crashes the latest nightly (Oct 20) Windows version as well.

Comment 106

14 years ago
Attachment 162811 [details] crashes for me on Windows 2000 Pro SP4 (talkback ID
TB1438231G). I've never gotten any of the popup crashes on this machine, FWIW.

Mozilla/5.0 (Windows; U; Windows NT 5.0; rv:1.7.3) Gecko/20040913 Firefox/0.10.1
So I'm trying to make sense of what's going on here in all the noise...  the
real problem is that the frame code canceling mImageRequest triggers onload,
which destroys the frame, then we access members on the frame, right?  

An added twist is that we end up triggering the style change from UpdateImage()
which is ultimately called from AttributeChanged().  So the calls look like:

CSSFrameConst::AttributeChanged(src)
  nsImageBoxFrame::AttributeChanged
    nsImageBoxFrame::UpdateImage
      // onload fires, style changes
        CSSFrameConst::AttributeChanged(style)
          // frame destroyed
  ProcessRestyledFrames() (on the already-destroyed frame)

I suspect this is what causes the crash even with the "low risk patch for
branch", but I'm not sure what the stack for that crash was...

For the rest, frames are indeed not created till StartLayout() is called.

So possible solutions are:

1)  Prevent onload from firing while we're in
    nsCSSFrameConstructor::AttributeChanged by tossing a dummy layout request
    into the loadgroup.
2)  Do UpdateImage() off a PLEvent.

On trunk, I bet we could achieve the same effect by removing the node from the
document in onload instead of just setting it to display:none, since that will
cause sync frame destruction.  So we probably need to do something about this on
the trunk too.
 3) set chromehidden at a reasonable time (would work for the branch, although
we'd still want to fix the underlying bug)
Created attachment 162906 [details] [diff] [review]
plevent patch for branch

An issue darin pointed out about using a dummy request for onload prevention in
cases like this is that somebody could change document.location() to cancel the
loadgroup.  (Although I guess that hopefully wouldn't fire onload.)

Anyway, this is a plevent patch.  I'll test the Mac shortly, but it fixes both
testcases.
Comment on attachment 162906 [details] [diff] [review]
plevent patch for branch

Yeah, this does really fix the crash on the Mac.
Attachment #162906 - Flags: superreview?(darin)
Attachment #162906 - Flags: review?(bzbarsky)

Updated

14 years ago
Whiteboard: [useful comments: 46-47, 63, 67, 75-77, 94] → has patch needs reviews [useful comments: 46-47, 63, 67, 75-77, 94]
Hrm, but it really doesn't do the right things with onerror notifications and
anything else that the listener cares about...
Created attachment 162946 [details] [diff] [review]
plevent patch for branch
Attachment #162906 - Attachment is obsolete: true
Comment on attachment 162946 [details] [diff] [review]
plevent patch for branch

So this still changes our behavior regarding onerror, but I don't think it's
that serious, and this version is a little more consistent than the previous
patch about it.
Attachment #162946 - Flags: superreview?(darin)
Attachment #162946 - Flags: review?(bzbarsky)
Attachment #162906 - Flags: superreview?(darin)
Attachment #162906 - Flags: review?(bzbarsky)
Created attachment 162948 [details] [diff] [review]
plevent patch for branch
Attachment #162946 - Attachment is obsolete: true

Comment 115

14 years ago
Comment on attachment 162948 [details] [diff] [review]
plevent patch for branch

sr=darin assuming bz is happy.

we should file a bug on the fact that it isn't possible to tell if we should
call PL_DestroyEvent when PL_PostEvent fails.
Attachment #162948 - Flags: superreview+
Created attachment 162949 [details] [diff] [review]
plevent patch for branch
Attachment #162948 - Attachment is obsolete: true

Updated

14 years ago
Attachment #162949 - Flags: superreview+
Attachment #162946 - Flags: superreview?(darin)
Attachment #162946 - Flags: review?(bzbarsky)
Attachment #162949 - Flags: review?(bzbarsky)
Comment on attachment 162949 [details] [diff] [review]
plevent patch for branch

Calling DisconnectListener() drops the ref to it, but the problem is that image
requests hold a weak ref to the listener.  See
http://lxr.mozilla.org/seamonkey/source/modules/libpr0n/public/imgILoader.idl#7
9

So this patch, as written, could cause the imgRequest to make a call on a
deleted listener (say if the frame is animated and we animate the next frame
before the cancellation event fires).  We need to make the event hold a ref to
the listener too and release the listeners only after it has cancelled the
requests.

r-, based on that.
Attachment #162949 - Flags: review?(bzbarsky) → review-
Created attachment 162984 [details] [diff] [review]
plevent patch for branch

I think this addresses bz's comments.
Attachment #162949 - Attachment is obsolete: true
Attachment #162984 - Flags: superreview?(darin)
Attachment #162984 - Flags: review?(bzbarsky)
Comment on attachment 162984 [details] [diff] [review]
plevent patch for branch

Yes, this works.  r=bzbarsky.
Attachment #162984 - Flags: review?(bzbarsky) → review+

Comment 120

14 years ago
no longer crashes on 20041022.

Comment 121

14 years ago
Comment on attachment 162984 [details] [diff] [review]
plevent patch for branch

sr=darin

good catch, bz!
Attachment #162984 - Flags: superreview?(darin) → superreview+

Comment 122

14 years ago
Comment on attachment 162984 [details] [diff] [review]
plevent patch for branch

a=asa for aviary checkin.
Attachment #162984 - Flags: approval-aviary+
Fix checked in to AVIARY_1_0_20040515_BRANCH, 2004-10-22 13:41 -0700.
Fix checked in to MOZILLA_1_7_BRANCH, 2004-10-22 13:44 -0700.

(While I was there, I noticed nsContentUtils::CanLoadImage returns a boolean on
the former branch and an nsresult on the latter branch.  That seems highly
dangerous.)
Keywords: fixed-aviary1.0, fixed1.7.x
(In reply to comment #123)
> (While I was there, I noticed nsContentUtils::CanLoadImage returns a boolean on
> the former branch and an nsresult on the latter branch.  That seems highly
> dangerous.)

Yeah, that already bit me (luckily I caught it before checking in what I was
working on). But I don't think we want to change that now...
*** Bug 266211 has been marked as a duplicate of this bug. ***

Comment 126

14 years ago
I've been experiencing the same issue: any javascript pop-up would cause my
Firefox browser to crash. Mac OS X 10.3.5, Firefox 1.0PR. The interesting thing
is that it seemed dependent on how many open tabs I had -- if there were only
three or four tabs open, the pop-up would come up. But if I had about a dozen
tabs open like I normally do, javascript pop-ups would crash Firefox every time.

Well, tonight I downloaded 1.0RC1 to replace 1.0PR -- and the problem is
completely gone. I can open up fifteen browser tabs, then click on one
javascript pop-up link after another. All the pop-ups come up properly with nary
a crash.

Congratulations, developers -- I think you're nailed this bug.

Updated

14 years ago
No longer blocks: 258943
*** Bug 258943 has been marked as a duplicate of this bug. ***

Comment 128

14 years ago
I am no longer crashing with the testcases in this bug and in Talkback data
using the latest Firefox 1.0 RC1 release, so looks like the crash is gone.  Are
we leaving this open for some more work or should we mark this fixed?
It's not fixed on the trunk.
Whiteboard: has patch needs reviews [useful comments: 46-47, 63, 67, 75-77, 94] → [patch][useful comments: 46-47, 63, 67, 75-77, 94]

Comment 130

14 years ago
Can we set 'Firefox 1.1' as the target for this bug ? I'm asking this, because
there's no 'blocking-aviary1.1' flag or something similar. Sorry for the bugspam.

Comment 131

14 years ago
Setting targets is something for the developers to do, and there's no need for
bug spam to point it out to them. If it doesn't get fixed by the time that 1.1
is imminent (in a few months), that would be the time for others to worry about
it (with a blocking nomination I would guess).  I'll set version to trunk though.
Version: 1.0 Branch → Trunk
I'm not able to reproduce a crash with any of the test cases on recent trunk builds

wfm
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → WORKSFORME
(In reply to comment #132)
> I'm not able to reproduce a crash with any of the test cases on recent trunk
builds
> 
> wfm

The patch was never checked in to the trunk. The original testcase does't crash
the trunk because the underlying bug was obfuscated by some unrelated JS changes
made on the trunk. 
David Baron's testcase doesn't crash recent trunk builds for me either, but I'm
still a bit worried that the underlying bug wasn't really fixed, and might be
exposed again at some point in the future.
I would recommend keeping the bug open until David Baron verifies that the root
cause of it had indeed been fixed. 
I filed bug 279171 as a followup, although we may need an additional followup
bug as well.

Comment 135

9 years ago
I got this same error with v3.52 of firefox. As soon as I goto a page with working java it crashes.No workaround so I deleted everything and tried to re-install, same results. I am now working with v3.0.10. Works fine.
Waiting for this issue to be resolved.
Crash Signature: [@ 0x00000000 - nsCOMPtr_base::assign_with_AddRef ]
You need to log in before you can comment on or make changes to this bug.