Crash combining JavaScript "Harmony" forwarding proxy with DOMParser-generated document

RESOLVED FIXED

Status

()

defect
--
critical
RESOLVED FIXED
9 years ago
4 years ago

People

(Reporter: WeirdAl, Assigned: automation)

Tracking

({crash, testcase})

Trunk
x86_64
All
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(blocking2.0 final+)

Details

(Whiteboard: [hardblocker] fixed-in-tracemonkey)

Attachments

(4 attachments, 1 obsolete attachment)

Posted file crash testcase
I was tinkering around with JavaScript proxies, first trying it with a pure JavaScript object.  Then I tried it with a nsIDOMDocument on FF4 beta 8, Fedora 14, and my CPU started spinning endlessly.  I tried to reproduce it on Windows 7 x64 with FF4 trunk, and crashed.
Without the onload call, I crash on Windows x64, but MSVC 2008 Express is not able to trap the assertion failure, and FF4 simply crashes on the same line:

Assertion failure: wrapper->isWrapper(), at c:/trunk/base/mozilla/js/src/xpconnect/wrappers/AccessCheck.cpp:370
blocking2.0: --- → ?
Hardware: x86 → x86_64
gal, mrbkap:  can one of you please explain what the assertion failure means?
JS_ASSERT(wrapper->isWrapper());

I'm just looking for a little insight, to see if there's anything I can do or learn from this.
jst: I nominated this for blocking FF4 7 days ago.  What do you think: hardblocker, softblocker, notablocker?
Its at least a crash so we should look at it. Probably an easy fix.
blocking2.0: ? → betaN+
QA Contact: xpconnect → gal
Assignee: nobody → gal
blocking2.0: betaN+ → final+
QA Contact: gal → xpconnect
Whiteboard: [hardblocker]
This WFM with TM debug. I think bug 626290 fixed this.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WORKSFORME
(In reply to comment #5)
> This WFM with TM debug. I think bug 626290 fixed this.

I'd appreciate a cc on that bug, please.

When you said "WFM", did you mean it wasn't crashing, or that it was generating useful results?  (I realize the data variable's contents didn't end up in the "output" textarea afterwards... I guess I over-minimized the testcase in that respect.)
Group: core-security
I shouldn't have linked a hidden bug from an open bug with a test case. I will hide this one. Alex, I added you to the other one as well. I only checked that we no longer crash.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Posted patch patchSplinter Review
Attachment #505631 - Flags: review?(mrbkap)
Actually we need another spot fix for this after all. Alex, I will land this patch shortly. After that please try your test case with the tracemonkey nightly if you can.
Attachment #505631 - Flags: review?(mrbkap) → review+
cdleary-bot mozilla-central merge info:
http://hg.mozilla.org/mozilla-central/rev/b03242ce2fce
Note: not marking as fixed because fixed-in-tracemonkey is not present on the whiteboard.
Posted patch further testcase (obsolete) — Splinter Review
Further testing shows this isn't enough.  Sure, we fixed the crash, and it's not hanging... but it throws NS_ERROR_XPC_BAD_CONVERT_JS calling doc.getElementById("test").

I'm not sure this should still be a hardblocker based on that (it's a bug in a very new feature)... but I can't say this is fixed to my satisfaction.

(I am aware that in this testcase, several values will come up false, because proxies don't support equality comparisons directly.  That's fine - I have other JS proxy code I've written to take care of that.)
Alex, can you file a new bug with the new test case? We will fix it there. Please cc me.
Filed as bug 627634.
Status: REOPENED → RESOLVED
Closed: 9 years ago9 years ago
Resolution: --- → FIXED
Whiteboard: [hardblocker] → [hardblocker] fixed-in-tracemonkey
OK, 627634 was invalid.  However, I discovered further proxy oddities in bug 627648.
Attachment #505694 - Attachment is obsolete: true
Assignee: gal → automation
Group: core-security → core-security-release
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.