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
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
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
Last Resolved: 11 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 373393
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.
You need to log in before you can comment on or make changes to this bug.