Closed Bug 407331 Opened 17 years ago Closed 17 years ago

Assertion on running a fresh trunk build

Categories

(Core :: General, defect)

Product:
Core
Component:
General
Platform:
x86
Windows Vista
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: ehsan.akhgari, Unassigned)

References

(
URL
)

Details

(Keywords: assertion, crash)

Attachments

(1 file)

Stack trace
76.10 KB, text/plain
Details 
###!!! ASSERTION: QueryInterface needed: 'query_result.get() == mRawPtr', file c:\mozroot\mozilla\obj-ff-opt\dist\include\xpcom\nsCOMPtr.h, line 594

This is a fresh Vista machine, with a fresh install of VC8 Express, PSDK, MozillaBuild, and a fresh CVS pull of the code.  Every attempt to run the build leads to this assertion.  After dismissing this assertion by clicking Ignore 4 times (just to get the same assertion again), I get a baloon prompt from Windows stating that Data Execution Prevention has closed Firefox to help protect my computer!  Clicking Abort terminates firefox.exe.  Clicking Retry does not launch the debugger; just terminates firefox.exe.

Here's my .mozconfig file:

. $topsrcdir/browser/config/mozconfig

mk_add_options MOZ_CO_PROJECT=browser
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/obj-ff-opt
mk_add_options MOZ_MAKE_FLAGS=-j4

ac_add_options --enable-optimize
ac_add_options --disable-debug
ac_add_options --enable-libxul
Please set XPCOM_DEBUG_BREAK=trap and then tell us what the call stack
is when the assertion occurs.
http://developer.mozilla.org/en/docs/XPCOM_DEBUG_BREAK
Keywords: stackwanted
Attached file Stack trace — 
I ran with XPCOM_DEBUG_BREAK=stack, and attached the *whole* output below.
Stack trace submitted.
Keywords: stackwanted
That stack trace does not makes much sense to me.
Could you try XPCOM_DEBUG_BREAK=trap and see if the VC8 debugger
gives a better result?  Thanks.
Like I said in comment 0, hitting Retry on the assertion dialog does not pop up the debugger.  Anyway, I tried starting firefox.exe from the VC8 IDE, and got a stack trace when the breakpoint was hit.  Here's the stack trace.  I'm not sure if it's more usable than the one I already attached to the bug:

 	ntdll.dll!775f2ea8() 	
 	[Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll]	
 	xul.dll!10b431de() 	
 	ntdll.dll!77612447() 	
 	ntdll.dll!77661ec8() 	
 	ntdll.dll!7762d9fa() 	
 	ntdll.dll!77612033() 	
 	ntdll.dll!77612447() 	
 	ntdll.dll!7761214c() 	
 	xul.dll!10b10110() 	
>	nspr4.dll!_MD_CURRENT_THREAD()  Line 298 + 0xc bytes	C
 	msvcr80d.dll!001e4e89() 	
 	msvcr80d.dll!001e7769() 	
 	msvcr80d.dll!0022edc6() 	
 	msvcr80d.dll!001e3ca4() 	
 	msvcr80d.dll!001e3ca4() 	
 	msvcr80d.dll!001fe039() 	
 	msvcr80d.dll!001fe4ab() 	
 	msvcr80d.dll!001fe4a0() 	
 	xul.dll!10b42d02() 	
 	ntdll.dll!77612447() 	
 	ntdll.dll!7761214c() 	
 	ntdll.dll!77660f2b() 	
 	ntdll.dll!77660f2b() 	
 	ntdll.dll!776617ab() 	
 	ntdll.dll!7766178f() 	
 	ntdll.dll!7762d9fa() 	
 	ntdll.dll!7766178f() 	
 	ntdll.dll!7762dc7e() 	
 	ntdll.dll!77612447() 	
 	ntdll.dll!775c898e() 	
 	ntdll.dll!7764c8a3() 	
 	ntdll.dll!7764c8a3() 	
 	ntdll.dll!77612447() 	
 	ntdll.dll!7761214c() 	
 	xul.dll!10b11376() 	
 	xul.dll!10b11376() 	
 	xul.dll!107dcd05() 	
 	msvcr80d.dll!001e3ca4() 	
 	xul.dll!107f3ac8() 	
 	nspr4.dll!_MD_CURRENT_THREAD()  Line 298 + 0xc bytes	C
 	nspr4.dll!PR_GetCurrentThread()  Line 175	C
 	80004002()	
 	xul.dll!10b4151d() 	
 	xul.dll!101866b2() 	
 	xul.dll!100e5898() 	
 	xul.dll!10166deb() 	
 	xul.dll!1063db2c() 	
 	xul.dll!104ea4f5() 	
 	nspr4.dll!00380000() 	
 	nspr4.dll!PR_GetCurrentThread()  Line 175	C
 	0343df54()	
 	nspr4.dll!_MD_CURRENT_THREAD()  Line 298 + 0xc bytes	C
 	nspr4.dll!PR_GetCurrentThread()  Line 175	C
 	nspr4.dll!PR_GetThreadPrivate(unsigned int index=1)  Line 232 + 0x5 bytes	C
 	xul.dll!10b3507b() 	
 	xul.dll!10b4151d() 	
 	xul.dll!10264a82() 	
 	xul.dll!10264aed() 	
 	xul.dll!1075611b() 	
 	xul.dll!10226167() 	
 	xul.dll!102b9a53() 	
 	xul.dll!10264acb() 	
 	xul.dll!102a3f66() 	
 	xul.dll!10294a01() 	
 	xul.dll!10b436c2() 	
 	xul.dll!102a3ad6() 	
 	xul.dll!100a68cf() 	
 	xul.dll!10800e00() 	
 	xul.dll!10801e94() 	
 	xul.dll!100a68cf() 	
 	xul.dll!108091f7() 	
 	xul.dll!102074bc() 	
 	xul.dll!1080182d() 	
 	xul.dll!107f3ac8() 	
 	xul.dll!107f3c4d() 	
 	nspr4.dll!_MD_CURRENT_THREAD()  Line 298 + 0xc bytes	C
 	nspr4.dll!PR_GetCurrentThread()  Line 175	C
 	nspr4.dll!PR_GetThreadPrivate(unsigned int index=0)  Line 232 + 0x5 bytes	C
 	xul.dll!10b3441b() 	
 	xul.dll!107d2a47() 	
 	xul.dll!104b24d7() 	
 	xul.dll!10b4156d() 	
 	xul.dll!102074bc() 	
 	xul.dll!107d2b70() 	
 	xul.dll!109265d3() 	
 	xul.dll!10b41772() 	
 	xul.dll!1009a3cc() 	
 	xul.dll!102495e3() 	
 	xul.dll!1049fb11() 	
 	xul.dll!1081dafe() 	
 	xul.dll!1081aebb() 	
 	ntdll.dll!77612447() 	
 	ntdll.dll!7761214c() 	
 	ntdll.dll!77660f2b() 	
 	ntdll.dll!77660f2b() 	
 	ntdll.dll!776617ab() 	
 	ntdll.dll!7766178f() 	
 	ntdll.dll!7766178f() 	
 	ntdll.dll!77612447() 	
 	ntdll.dll!77612447() 	
 	ntdll.dll!77612447() 	
 	ntdll.dll!7761214c() 	
 	nspr4.dll!_MD_CURRENT_THREAD()  Line 298 + 0xc bytes	C
 	nspr4.dll!PR_GetCurrentThread()  Line 175	C

I'm not sure how to get the symbol information for xul.pdb.  If it helps, I can setup MS symbol servers in VC8 to get symbolic information for the ntdll.dll entries.  If that helps, please let me know.
There is a symbol server for Firefox trunk nightly builds:
http://developer.mozilla.org/en/docs/Using_the_Mozilla_symbol_server
I'm not sure if that can be used with your own build though...

Or you could rebuild with symbols enabled:
http://developer.mozilla.org/en/docs/Building_Firefox_with_Debug_Symbols
Product: Firefox → Core
QA Contact: general → general
OK, I enabled MS symbol servers in VC8, and I rebuilt with debugging information, and re-ran the test in VC.  Here's what I got this time.  I believe this to be a different crash though.  By the way, running the new build from the command line leads to a silent crash, and no assertion.

 	ntdll.dll!@RtlpLowFragHeapFree@8()  + 0x2c bytes	
 	ntdll.dll!_RtlFreeHeap@12()  + 0x7a bytes	
 	kernel32.dll!_HeapFree@12()  + 0x14 bytes	
 	msvcr80.dll!_free()  + 0xcd bytes	
>	xul.dll!nsStandardURL::Resolve(const nsACString_internal & in={...}, nsACString_internal & out={...})  Line 1801 + 0x7 bytes	C++
 	xul.dll!RDFContentSinkImpl::GetIdAboutAttribute(const unsigned short * * aAttributes=0x01e84b30, nsIRDFResource * * aResource=0x0012ed80, int * aIsAnonymous=0x00000000)  Line 885 + 0x20 bytes	C++
 	xul.dll!RDFContentSinkImpl::OpenObject(const unsigned short * aName=0x01e8acc8, const unsigned short * * aAttributes=0x01e84b30)  Line 1192 + 0x2f bytes	C++
 	xul.dll!RDFContentSinkImpl::HandleStartElement(const unsigned short * aName=0x01e8acc8, const unsigned short * * aAtts=0x01e84b30, unsigned int aAttsCount=8, int aIndex=-1, unsigned int aLineNumber=5)  Line 484	C++
 	xul.dll!nsExpatDriver::HandleStartElement(const unsigned short * aValue=0x01e8acc8, const unsigned short * * aAtts=0x01e84b30)  Line 426	C++
 	xul.dll!Driver_HandleStartElement(void * aUserData=0x0168ac90, const unsigned short * aName=0x01e8acc8, const unsigned short * * aAtts=0x01e84b30)  Line 96	C++
 	xul.dll!doContent(XML_ParserStruct * parser=0x01e84900, int startTagLevel=0, const encoding * enc=0x10698dd0, const char * s=0x026ace00, const char * end=0x026ae4a2, const char * * nextPtr=0x0012ef88, unsigned char haveMore='')  Line 2464 + 0xe bytes	C
 	xul.dll!contentProcessor(XML_ParserStruct * parser=0x01e84900, const char * start=0x026acc9c, const char * end=0x026ae4a2, const char * * endPtr=0x0012ef88)  Line 2095 + 0x2a bytes	C
 	xul.dll!doProlog(XML_ParserStruct * parser=0x01e84900, const encoding * enc=0x10698dd0, const char * s=0x026acc9c, const char * end=0x026ae4a2, int tok=16777228, const char * next=0x026acc9c, const char * * nextPtr=0x0012ef88, unsigned char haveMore='')  Line 4075 + 0x19 bytes	C
 	xul.dll!prologProcessor(XML_ParserStruct * parser=0x01e84900, const char * s=0x026acc9a, const char * end=0x026ae4a2, const char * * nextPtr=0x0012ef88)  Line 3810 + 0x22 bytes	C
 	xul.dll!prologInitProcessor(XML_ParserStruct * parser=0x01e84900, const char * s=0x026acc70, const char * end=0x026ae4a2, const char * * nextPtr=0x0012ef88)  Line 3626 + 0x1c bytes	C
 	xul.dll!MOZ_XML_Parse(XML_ParserStruct * parser=0x01e84900, const char * s=0x026acc70, int len=6194, int isFinal=0)  Line 1528 + 0x1f bytes	C
 	xul.dll!nsExpatDriver::ParseBuffer(const unsigned short * aBuffer=0x026acc70, unsigned int aLength=3097, int aIsFinal=0, unsigned int * aConsumed=0x0012f030)  Line 994 + 0x14 bytes	C++
 	xul.dll!nsExpatDriver::ConsumeToken(nsScanner & aScanner={...}, int & aFlushTokens=0)  Line 1098	C++
 	xul.dll!nsParser::Tokenize(int aIsFinalChunk=0)  Line 2372 + 0x14 bytes	C++
 	xul.dll!nsParser::ResumeParse(int allowIteration=1, int aIsFinalChunk=0, int aCanInterrupt=1)  Line 1598 + 0xe bytes	C++
 	xul.dll!nsParser::OnDataAvailable(nsIRequest * request=0x02545c04, nsISupports * aContext=0x00000000, nsIInputStream * pIStream=0x02582f18, unsigned int sourceOffset=0, unsigned int aLength=3097)  Line 2238	C++
 	xul.dll!RDFXMLDataSourceImpl::OnDataAvailable(nsIRequest * request=0x02545c04, nsISupports * ctxt=0x00000000, nsIInputStream * inStr=0x02582f18, unsigned int sourceOffset=0, unsigned int count=3097)  Line 1129	C++
 	xul.dll!RDFXMLDataSourceImpl::BlockingParse(nsIURI * aURL=0x00000c19, nsIStreamListener * aConsumer=0x00000000)  Line 552 + 0x13 bytes	C++
 	xul.dll!RDFXMLDataSourceImpl::Refresh(int aBlocking=1)  Line 923	C++
 	xul.dll!RDFServiceImpl::GetDataSource(const char * aURI=0x025b9300, int aBlock=1, nsIRDFDataSource * * aDataSource=0x0012f2d8)  Line 1481	C++
 	xul.dll!RDFServiceImpl::GetDataSourceBlocking(const char * aURI=0x025b9300, nsIRDFDataSource * * aDataSource=0x0012f2d8)  Line 1410	C++
 	xul.dll!NS_InvokeByIndex_P(nsISupports * that=0x100272ad, unsigned int methodIndex=39009096, unsigned int paramCount=16, nsXPTCVariant * params=0x00000002)  Line 102	C++
 	xul.dll!AutoJSSuspendRequest::SuspendRequest()  Line 3361 + 0x9 bytes	C++
 	nspr4.dll!PR_AtomicDecrement(int * val=0x02533b48)  Line 312 + 0x9 bytes	C
 	xul.dll!XPCWrappedNative::CallMethod(XPCCallContext & ccx={...}, XPCWrappedNative::CallMode mode=CALL_METHOD)  Line 2347 + 0x15 bytes	C++
 	xul.dll!XPC_WN_CallMethod(JSContext * cx=0x02652078, JSObject * obj=0x013c3660, unsigned int argc=1, long * argv=0x02532f48, long * vp=0x0012f550)  Line 1467 + 0xa bytes	C++
 	js3250.dll!js_Invoke(JSContext * cx=0x00000001, unsigned int argc=1, long * vp=0x026a8430, unsigned int flags=0)  Line 1356 + 0x11 bytes	C
 	js3250.dll!js_Interpret(JSContext * cx=0x02652078, unsigned char * pc=0x02566f74, long * result=0x0012f764)  Line 4175 + 0x11 bytes	C
 	js3250.dll!js_Invoke(JSContext * cx=0x00000001, unsigned int argc=0, long * vp=0x026a82e4, unsigned int flags=2)  Line 1376 + 0xf bytes	C
 	js3250.dll!js_InternalInvoke(JSContext * cx=0x02652078, JSObject * obj=0x013c32e0, long fval=21037536, unsigned int flags=0, unsigned int argc=40534748, long * argv=0x00000000, long * rval=0x0012f948)  Line 1432 + 0xf bytes	C
 	js3250.dll!js_InternalGetOrSet(JSContext * cx=0x02652078, JSObject * obj=0x013c32e0, long id=20200364, long fval=21037536, JSAccessMode mode=JSACC_READ, unsigned int argc=0, long * argv=0x00000000, long * rval=0x0012f948)  Line 1495 + 0x17 bytes	C
 	js3250.dll!js_NativeGet(JSContext * cx=0x02652078, JSObject * obj=0x013c32e0, JSObject * pobj=0x01420720, JSScopeProperty * sprop=0xffffffff, long * vp=0x0012f948)  Line 3528 + 0x27 bytes	C
 	js3250.dll!js_GetProperty(JSContext * cx=0x0171d0d0, JSObject * obj=0x013c32e0, long id=20200364, long * vp=0x0012f948)  Line 3671 + 0x10 bytes	C
 	js3250.dll!js_Interpret(JSContext * cx=0x02652078, unsigned char * pc=0x0255de40, long * result=0x0012fa08)  Line 3819 + 0x16 bytes	C
 	js3250.dll!js_Invoke(JSContext * cx=0x00000001, unsigned int argc=1, long * vp=0x026a8000, unsigned int flags=2)  Line 1376 + 0xf bytes	C
 	xul.dll!nsXPCWrappedJSClass::CallMethod(nsXPCWrappedJS * wrapper=0x0252ddb0, unsigned short methodIndex=3, const XPTMethodDescriptor * info=0x02571540, nsXPTCMiniVariant * nativeParams=0x0012fbcc)  Line 1443 + 0x12 bytes	C++
 	xul.dll!nsXPCWrappedJS::CallMethod(unsigned short methodIndex=3, const XPTMethodDescriptor * info=0x02571540, nsXPTCMiniVariant * params=0x0012fbcc)  Line 568	C++
 	xul.dll!PrepareAndDispatch(nsXPTCStubBase * self=0x0252de00, unsigned int methodIndex=3, unsigned int * args=0x0012fc84, unsigned int * stackBytesToPop=0x0012fc74)  Line 114 + 0x15 bytes	C++
 	xul.dll!SharedStub()  Line 142	C++
 	xul.dll!XRE_main(int argc=21261784, char * * argv=0x01446e20, const nsXREAppData * aAppData=0x01446e68)  Line 3081	C++
 	00cf4b20()	
 	nspr4.dll!PR_AtomicDecrement(int * val=0x00cf4a4c)  Line 312 + 0x9 bytes	C
 	xul.dll!nsLocalFile::Release()  Line 751 + 0x10 bytes	C++
 	xul.dll!nsLocalFile::GetParent(nsIFile * * aParent=0x10002ab2)  Line 2182 + 0x1f bytes	C++
 	xul.dll!nsRefPtr<nsPluginStreamListenerPeer>::~nsRefPtr<nsPluginStreamListenerPeer>()  Line 957	C++
 	firefox.exe!main(int argc=, char * * argv=)  Line 154	C++

Let me know if I can provide more info.

I'm also posting the new .mozconfig, to show that there's nothing different than the one in comment 0, other than the option to enable building debug info.  I also have not updated the code from the CVS, so this is the same code that I built from the last time.  The only difference that I can think of is running make distclean before this build, since linking xul.dll lead to undefined symbols when I switched on the debug info.

. $topsrcdir/browser/config/mozconfig

mk_add_options MOZ_CO_PROJECT=browser
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/obj-ff-opt
mk_add_options MOZ_MAKE_FLAGS=-j4

ac_add_options --enable-optimize
ac_add_options --disable-debug
ac_add_options --enable-libxul

export MOZ_DEBUG_SYMBOLS=1
ac_add_options --enable-debugger-info-modules=yes
Keywords: crash
Has anyone been able to reproduce it?  If it helps, I'm willing to contribute my builds for you guys to test && debug...
I reduced the .mozconfig file to the following, and updated the code from CVS, and built a fresh version, and the problem persists.

. $topsrcdir/browser/config/mozconfig

mk_add_options MOZ_CO_PROJECT=browser
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/obj-ff-opt
mk_add_options MOZ_MAKE_FLAGS=-j4

export MOZ_DEBUG_SYMBOLS=1
ac_add_options --enable-debugger-info-modules=yes

I've uploaded my build so that it can be tested and debugged if necessary.  This problem is preventing me from hacking on Firefox on this machine :-(

<http://ce.sharif.edu/~akhgari/firefox/builds/firefox-crasher-20071210.win32.zip>
URL: http://ce.sharif.edu/~akhgari/firefox...
FWIW, I updated my MozillaBuild to 1.2, and updated my CVS copy last night, and built.  The new build indeed works without the assertions I've been witnessing previously.
Glad to hear it's working now.  Maybe you were just unlucky the first time
and pulled a broken tree.  FWIW, I always make sure Tinderbox is green before
updating my trees.  http://tinderbox.mozilla.org/showbuilds.cgi?tree=Firefox

-> WORKSFORME
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → WORKSFORME
(In reply to comment #11)
> Glad to hear it's working now.  Maybe you were just unlucky the first time
> and pulled a broken tree.  FWIW, I always make sure Tinderbox is green before
> updating my trees.  http://tinderbox.mozilla.org/showbuilds.cgi?tree=Firefox
> 
> -> WORKSFORME

Me too.  In fact, the tree was green when I refreshed my sources previously.  I'm positive that it was not a problem with a broken tree, but I guess now we can't verify this claim any more...
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: