Last Comment Bug 373594 - Missing quotes around string in decompilation, with E4X @foo
: Missing quotes around string in decompilation, with E4X @foo
: testcase
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: Trunk
: x86 Mac OS X
-- normal (vote)
: ---
Assigned To: general
: Jason Orendorff [:jorendorff]
Depends on:
Blocks: jsfunfuzz e4x
  Show dependency treegraph
Reported: 2007-03-11 20:11 PDT by Jesse Ruderman
Modified: 2011-11-16 18:23 PST (History)
5 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

Another missing inXML = JS_FALSE (1019 bytes, patch)
2007-03-11 22:08 PDT, Jeff Walden [:Waldo] (remove +bmo to email)
mrbkap: review+
Details | Diff | Splinter Review

Description User image Jesse Ruderman 2007-03-11 20:11:45 PDT
js> function() { (@foo += 1)("a b c"); }
function () {
    (@foo += 1)(a b c);
Comment 1 User image Jeff Walden [:Waldo] (remove +bmo to email) 2007-03-11 22:08:24 PDT
Created attachment 258266 [details] [diff] [review]
Another missing inXML = JS_FALSE

I suspect pretty much all the bugs that hit the JSOP_ADD assertion are due to bad inXML logic.  This particular one looks like inXML needs to be reset for JSOP_BINDXMLNAME.  A slightly simpler (bytecode-wise) testcase:

function() { @foo = "5";  return "a\\b"; }

Also, some other testcases which work with latest trunk:

function() { @f(); "a\\".length; } // suspect this one was broken before today
function() { n::b(); "a\\b".length; }
function() { * = "5"; "a\\b".length; }

Do we have any sort of descriptions anywhere of exactly how the E4X bytecodes combine to produce correct logic, other than as the source code?  I can use dis and play whack-a-mole all I want, but it seems it'd be better/faster to refer to documentation of bytecode semantics and fix all these bugs at once.
Comment 2 User image Blake Kaplan (:mrbkap) 2007-03-11 22:15:46 PDT
Comment on attachment 258266 [details] [diff] [review]
Another missing inXML = JS_FALSE

This is fine, but see bug 373595 for more whack-a-mole fun. I wonder if it's worth coming up with a better way of tracking this stuff (if one exists).
Comment 3 User image Jesse Ruderman 2007-04-02 18:42:58 PDT
Comment 4 User image Brendan Eich [:brendan] 2007-04-02 18:49:22 PDT
Fixed by patch for bug 372564 as well -- waldo pls. confirm by marking FIXED.

Comment 5 User image Nochum Sossonko [:Natch] 2010-10-06 08:51:01 PDT
These bugs are all part of a search I made for js bugs that are getting lost in transit:

They all have a review+'ed, non-obsoleted patch and are not marked fixed-in-tracemonkey or checkin-needed but have not seen any activity in 300 days. Some of these got lost simply because the assignee/patch provider never requested a checkin, or just because they were forgotten about.
Comment 6 User image Ryan VanderMeulen [:RyanVM] 2011-11-16 18:23:17 PST
WFM too.

Note You need to log in before you can comment on or make changes to this bug.