372482 - ASSERTION: Lying nsIInterfaceRequestor implementation!: '*aResult', file c:/src/mozilla/content/base/src/nsXMLHttpRequest.cpp, line 2080

Status: VERIFIED DUPLICATE of bug 373393

(Toolkit :: Add-ons Manager, defect)

Description

[Lars Huttar]

User-Agent:       Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; InfoPath.1; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30)
Build Identifier: CVS Thu Mar 1 13:06:45 CST 2007

I checked out the source from CVS on Thu Mar 1 13:06:45 CST 2007. (How do I find a revision number I should report? All the files have different version numbers. I'm a SVN user.)
I built firefox with --enable-debug --disable-optimize --disable-installer
The build was successful.
When I ran obj-i686-pc-mingw32/dist/bin/firefox.exe, I got lots of debugging output, followed by:
###!!! ASSERTION: wasDirty lied: 'Error', file c:/src/mozilla/layout/base/nsPresShell.cpp, line 3381
Firefox exited. It never opened a window.


Reproducible: Always

Steps to Reproduce:
1. Build firefox with debug on, optimization off
2. run obj-i686-pc-mingw32/dist/bin/firefox.exe
3.
Actual Results:  
Assertion, and firefox exits without ever opening a window. (If you [Ignore] the assertion, you get it again several more times, followed by
###!!! ASSERTION: Lying nsIInterfaceRequestor implementation!: '*aResult', file c:/src/mozilla/content/base/src/nsXMLHttpRequest.cpp, line 2080
several times.

Expected Results:  
Firefox opens a window and lets me browse.

Comment 1

[Lars Huttar]

P.S. this was built from the source from the trunk.

Comment 2

[Jesse Ruderman]

On Mac, I see the "wasDirty lied" assertion.  I see the "Lying nsIInterfaceRequestor implementation" assertion only if extension manager decides to check my extensions (which it does every time I switch builds lately...), in which case I get a dialog asking if I want to check extensions for updates (often behind other applications) instead of a browser window.

Comment 3

[Lars Huttar]

The build identifier was:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a3pre) Gecko/20070302
Minefield/3.0a3pre

(I got Fx to start by ignoring lots of asserts.)

Comment 4

[Jesse Ruderman]

"wasDirty lied" seems to be bug 363253.

> I got Fx to start by ignoring lots of asserts.

Oh, right.  If you're on Windows your only hope for now is to set XPCOM_DEBUG_BREAK=warn.  (With that setting you'll get a console message and maybe a beep for each assert, but no modal dialog.)

Hopefully fewer assertions will fire on every startup in the future...

Comment 5

[timeless]

if you're on windows, you have a lot more flexibility than that, see:
http://www.mozilla.org/build/windbgdlg.html

Comment 6

[timeless]

http://mxr.landfill.bugzilla.org/seamonkey/search?string=b225&find=idl%24&findi=&filter=&hitlimit=&tree=seamonkey

Found one matching line
b225
/docshell/base/nsIDocShell.idl, 
line 71 -- [scriptable, uuid(fbe2a673-4b8b-46a2-b225-398c52cc05cb)]

0 <TOP LEVEL> ["<unknown>":0]
1 [native frame]
0 anonymous(iid = {fbe2a673-4b8b-46a2-b225-398c52cc05cb}) ["dbg-firefox-i686-pc-mingw32/dist/bin/components/nsExtensionManager.js":242]
    this = [object Object]
1 [native frame]

js3250!js_Interpret(struct JSContext * cx = 0x01e9e440, unsigned char * pc = 0x01a6d55e ";", long * result = 0x0012f1b0)+0x13052
js3250!js_Invoke(struct JSContext * cx = 0x01e9e440, unsigned int argc = 1, unsigned int flags = 2)+0xbb2
xpc3250!nsXPCWrappedJSClass::CallMethod(class nsXPCWrappedJS * wrapper = 0x1367fe98, unsigned short methodIndex = 3, struct XPTMethodDescriptor * info = 0x00c79bf0, struct nsXPTCMiniVariant * nativeParams = 0x0012f518)+0xf7f
xpc3250!nsXPCWrappedJS::CallMethod(unsigned short methodIndex = 3, struct XPTMethodDescriptor * info = 0x00c79bf0, struct nsXPTCMiniVariant * params = 0x0012f518)+0x41
xpcom_core!PrepareAndDispatch(class nsXPTCStubBase * self = 0x1367fef8, unsigned int methodIndex = 3, unsigned int * args = 0x0012f5d8, unsigned int * stackBytesToPop = 0x0012f5c8)+0x323
xpcom_core!SharedStub(void)+0x16
gklayout!nsXMLHttpRequest::GetInterface(struct nsID * aIID = 0x0612cc38, void ** aResult = 0x0149fc4c)+0x11f
gklayout!nsXMLHttpRequest::GetInterface(struct nsID * aIID = 0x0612cc38, void ** aResult = 0x0149fc4c)+0x11f
xpcom_core!nsInterfaceRequestorAgg::GetInterface(struct nsID * aIID = 0x0612cc38, void ** aResult = 0x0149fc4c)+0x40
necko!nsHttpConnection::GetInterface(struct nsID * iid = 0x0612cc38, void ** result = 0x0149fc4c)+0xac
xpcom_core!NS_InvokeByIndex(class nsISupports * that = 0x0b94953c, unsigned int methodIndex = 3, unsigned int paramCount = 2, struct nsXPTCVariant * params = 0x11407d00)+0x27
xpcom_core!nsProxyObjectCallInfo::Run(void)+0x51
xpcom_core!nsProxyObjectCallInfo::Run(void)+0x51
xpcom_core!nsThread::ProcessNextEvent(int mayWait = 1, int * result = 0x0012f70c)+0x1a0
xpcom_core!NS_ProcessNextEvent_P(class nsIThread * thread = 0x00b6f568, int mayWait = 1)+0x56

Steps:
1. use windbgdlg and catch the assertion
2. walk out to the asserting line
3. set the execution pointer back to the GetInterface call
4. slowly walk into JavaScript (this takes a while)
5. when you reach a certain point in js_Interpret, you can
.call DumpJSStack();g
(windbg notation, you could use msvc or dbx or devenv or gdb)
6. use mxr to find out what interface that is.

The question is then:
*why* does xmlhttprequest think that BadCertListener is an nsIDocShell?!

Note: there are other ways to do this, the interface iid is available
necko!nsHttpConnection::GetInterface(struct nsID * iid = 0x0612cc38, void ** result = 0x0149fc4c)+0xac
You just need to take the first field from *iid and feed it to mxr (I foolishly tried to feed it to the wrong xpti.dat, and this didn't work), if you feed the iid to the *right* xpti.dat, that too would yield nsIDocShell.

To figure out which code is running, I actually took jesse's hint checked the file to determine that SetNotificationCallbacks is what stored the object, and mentally converted that to noticationCallbacks (this isn't strictly necessary, I could have used ident) and then searched for it:
http://mxr.landfill.bugzilla.org/seamonkey/search?string=notificationcallbacks&find=Ex.*Man

That yielded one file:

/toolkit/mozapps/extensions/src/nsExtensionManager.js.in, 
line 2378 -- request.channel.notificationCallbacks = new BadCertHandler();
line 6188 -- request.channel.notificationCallbacks = new BadCertHandler();

the top of that file has:
182 #include ../../shared/src/badCertHandler.js
opening the file link in a new window yielded:
http://mxr.landfill.bugzilla.org/seamonkey/source/toolkit/mozapps/shared/src/badCertHandler.js
which had a getInterface implementation:
http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/toolkit/mozapps/shared/src/badCertHandler.js&rev=1.1&mark=98-116#90

anyway, I had two ways of getting all the information i needed.

well, except for the "why does something think this is an nsIDocShell" and "why is the js code broken" bits. more after biesi reads :).

Comment 7

[Boris Zbarsky [:bzbarsky]]

> *why* does xmlhttprequest think that BadCertListener is an nsIDocShell?!

It doesn't.  It's just checking whether it is.  Which is still odd, as is the fact that nsXMLHttpRequest::GetInterface calls itself.  I'd love to know the IIDs, in a separate bug.

> "why is the js code broken"

Looks to me like XPConnect is what's broken (not converting Components.returnCode into an rv in the usual way).

Comment 8

[Boris Zbarsky [:bzbarsky]]

Oh, and I must say, just presenting what you found and not the whole debugging process would be a _lot_ more readable.

Comment 9

[Lars Huttar]

(In reply to comment #8)
> Oh, and I must say, just presenting what you found and not the whole debugging
> process would be a _lot_ more readable.

For a new moz developer like me, a view into (a specific example of) the whole debugging process is very helpful.

Maybe the best of both worlds is to present conclusions separately from the process, in their own easy-to-spot section.

Comment 10

[Nickolay_Ponomarev]

Duping to a bug with a patch. I do wonder how come this didn't turn up in my searches.

Comment 11

[timeless]

asqueella: not your fault, this bug was filed to worry about the other duplicate. i searched for lying nsiinterfacerequestor or something when i used gmail to find an instance.

fwiw, there's a bug /somewhere/ about the xpconnect problem. i haven't spent enough time investigating. it's on my todo list, i'm pretty sure it's a known bug that we run into about once a year.

Comment 12

[Nickolay_Ponomarev]

Ah, so this was resummarized after I searched...

The xpconnect bug is bug 287107, as mentioned in the bug report I duped this to.