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

VERIFIED DUPLICATE of bug 373393

Status

()

VERIFIED DUPLICATE of bug 373393
12 years ago
10 years ago

People

(Reporter: lars, Unassigned)

Tracking

(Blocks: 1 bug, {assertion})

Trunk
assertion
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

12 years ago
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.
(Reporter)

Comment 1

12 years ago
P.S. this was built from the source from the trunk.
Version: unspecified → Trunk

Comment 2

12 years ago
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.
OS: Windows XP → All
Hardware: PC → All

Updated

12 years ago
Blocks: 341986
(Reporter)

Comment 3

12 years ago
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

12 years ago
"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

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

Comment 6

12 years ago
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 :).
URL: n/a
Component: General → Extension/Theme Manager
QA Contact: general → extension.manager
Summary: on startup, ASSERTION: wasDirty lied: 'Error', nsPresShell.cpp 3381 → ASSERTION: Lying nsIInterfaceRequestor implementation!: '*aResult', file c:/src/mozilla/content/base/src/nsXMLHttpRequest.cpp, line 2080
> *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).
Oh, and I must say, just presenting what you found and not the whole debugging process would be a _lot_ more readable.
(Reporter)

Comment 9

12 years ago
(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

12 years ago
Duping to a bug with a patch. I do wonder how come this didn't turn up in my searches.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 12 years ago
Keywords: assertion
Resolution: --- → DUPLICATE
Duplicate of bug: 373393

Comment 11

12 years ago
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.
Status: RESOLVED → VERIFIED

Comment 12

12 years ago
Ah, so this was resummarized after I searched...

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

Updated

10 years ago
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.