5.48 KB, application/xhtml+xml
7.46 KB, text/plain
527 bytes, patch
|Details | Diff | Splinter Review|
893 bytes, text/html
Created attachment 501683 [details] stack trace when RunTest() is fired from onload 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
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.
Assignee: nobody → gal
blocking2.0: betaN+ → final+
QA Contact: gal → xpconnect
This WFM with TM debug. I think bug 626290 fixed this.
Status: NEW → RESOLVED
Last Resolved: 8 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.)
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.
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.
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.
Created attachment 505694 [details] [diff] [review] further testcase 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
Last Resolved: 8 years ago → 8 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
You need to log in before you can comment on or make changes to this bug.