I never saw bugmail from being cc'd on this bug. Hrm. Anyone see mail log traces saying why? Should this bug be WFM now, or FIXED? /be
This is windows as well as Linux. I don't think this is fixed at all -- unless something changed in the last couple of hours and bonsai doesn't show anything.
OS: Linux → All
> I never saw bugmail from being cc'd on this bug. Hrm. Anyone see mail log > traces saying why? All mozilla.org mail was bouncing for two hours today around the time I filed this bug after dbaron accidentally horked the aliases database. That's probably why you didn't receive mail about it (I didn't either). > Should this bug be WFM now, or FIXED? Neither unless something has changed since this afternoon, when I pulled and built again to confirm the bug on the tip. Note that bug 287490, the other regression from bug 287107 (which this bug may just be a dupe of), has since been reopened, as two users report that the patch on that bug didn't fix the problem for them.
Myk, can you breakpoint http://lxr.mozilla.org/mozilla/source/js/src/xpconnect/src/xpcjsid.cpp#900 and see why that's being hit? /be
> Myk, can you breakpoint > http://lxr.mozilla.org/mozilla/source/js/src/xpconnect/src/xpcjsid.cpp#900 and > see why that's being hit? rv=0x80004002 and srvc is a null pointer at line 900 when the app tries to load the feed service.
Assignee: dbradley → brendan
Attachment #178775 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Working with myk over IRC, finding that one thing that might be adding noise is a lack of nsISupports handling in JS-scripted QueryInterface impls. Myk fixed his to handle nsISupports and that moved the symptom. Could download code have a similar lack in one of its scripted QI impls? /be
Severity: normal → critical
Priority: -- → P1
Target Milestone: --- → mozilla1.8beta2
Fooey. I backed out. Something's not right in a bunch of places in our JS QI impls, which return null after setting Components.returnCode ineffectually (due to bug 287107). My fix for bug 287107 makes these QIs truly fail with NS_NOINTERFACE yet not throw, and that leaves callers unhappy. Keeping bug open to investigate more. /be
Severity: critical → major
<brendan> k, here's what happened <brendan> rev 1.73 of xpcwrappedjsclass.cpp regressed things so a JS method couldn't set Components.returnCode, and succeed (not throw or error out), yet have the returnCode propagate back to the XPConnected caller <brendan> that means these QueryInterface impls in JS, such as yours, are wasting their time setting Components.returnCode without also throwing (failing) <brendan> cuz it's never fetched via GetPendingResult in any xpconnect/src/*.cpp (grep yourself) on a success path <brendan> my fix for 287107 made these returnCode statements do what they used to <brendan> and that showed up bugs <brendan> your QI didn't handle nsISupports <brendan> and maybe download mgr bugs of that kind <brendan> i'll patch privately and debug more, later <myk> i'll do the same and see if i can fix any bugs in my components <brendan> i'll put the private patch up and then crash -- it's tricky
Technically fixed, again. Hope not to reopen if the private patch shakes out all the missing QI cases. /be
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.