Closed Bug 372482 Opened 18 years ago Closed 18 years ago

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

Categories

(Toolkit :: Add-ons Manager, defect)

defect
Not set
normal

Tracking

()

VERIFIED DUPLICATE of bug 373393

People

(Reporter: lars, Unassigned)

References

Details

(Keywords: assertion)

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.
P.S. this was built from the source from the trunk.
Version: unspecified → Trunk
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
Blocks: fx-noise
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.)
"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...
if you're on windows, you have a lot more flexibility than that, see: http://www.mozilla.org/build/windbgdlg.html
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.
(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.
Duping to a bug with a patch. I do wonder how come this didn't turn up in my searches.
Status: UNCONFIRMED → RESOLVED
Closed: 18 years ago
Keywords: assertion
Resolution: --- → DUPLICATE
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
Ah, so this was resummarized after I searched... The xpconnect bug is bug 287107, as mentioned in the bug report I duped this to.
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.