Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20060730 Minefield/3.0a1 Each of these statements crashes Firefox: ({ a:{} }) = 3 ({ a:[] }) = 3

The array doesn't even have to be empty; this also crashes Firefox: ({ a:[z] }) = 3

In a nightly build, js_DecompileValueGenerator appears at the top. In a debug build, FindPropertyValue appears at the top. Thread 0 Crashed: 0 FindPropertyValue + 592 (jsparse.c:1771) 1 CheckDestructuring + 884 (jsparse.c:1894) 2 AssignExpr + 832 (jsparse.c:3356) 3 Expr + 48 (jsparse.c:3276) 4 Statement + 11176 (jsparse.c:3064) 5 Statements + 280 (jsparse.c:1131) 6 js_CompileTokenStream + 212 (jsparse.c:501) 7 CompileTokenStream + 224 (jsapi.c:3808) 8 JS_CompileUCScriptForPrincipals + 148 (jsapi.c:3903) 9 JS_EvaluateUCScriptForPrincipals + 112 (jsapi.c:4325) ...

Works for me in trunk js shell: js> ({ a:{} }) = 3; typein:3: SyntaxError: missing variable name: typein:3: ({ a:{} }) = 3; typein:3: .....^ js> ({ a:[z] }) = 3; typein:4: TypeError: undefined has no properties Are you running trunk or 1.8.1 Firefox? /be

Sorry, missed the first line of comment 0. Anyone know how to reproduce in the js shell? From comment 2, this sounds like it may be a dup of bug 346642, but the FindPropertyValue crash is probably separate. Time for valgrind. /be

This WFM on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060730 Minefield/3.0a1 ({ a:{} }) = 3 SyntaxError on line 1: missing variable name ({ a:[] }) = 3 SyntaxError on line 1: missing variable name ({ a:[z] }) = 3 TypeError on line 1: undefined has no properties

WFM in my Minefield build, too. /be

Could someone else with a PPC Mac build (Minefield or JS shell) please confirm. /be

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20060730 Minefield/3.0a1 I get the crash also.

Ok, I could use some help -- the PPC Mac box here has no developer tools, and I'm booked on other bugs. If any kind soul can debug a bit and describe what he or she sees leading to the crash in the debug build case (js shell is easiest, Firefox ok too), and find me on IRC.... /be

Byte-order-dependent unsafe type union bug, can you believe it? No-brainer for 1.8.1. /be

A double containing the number 3, stored in the pn_u.dval member of the pn_u union, is 0x4008000000000000, which aliases the pn_u.head pointer of the list variant depending on byte order. On little-endian machines, the low 32 bits of zeros alias head and we get a nice null head pointer, which looks like an empty list. On PPC and other big-endian machines, we get 0x40080000 and crash. This fix must be taken, since other double values could be used to forge pointers, although I'm not sure how far one could forge before crashing. At the limit, this is a read privacy violation. Big thanks to Josh for debugging help. /be

Fixed on trunk. /be

Comment on attachment 231515 [details] [diff] [review] fix a=drivers, please land this on the MOZILLA_1_8_BRANCH.

Fixed on the 1.8 branch too. /be

Checking in regress-346645-01.js; /cvsroot/mozilla/js/tests/js1_7/expressions/regress-346645-01.js,v <-- regress-346645-01.js initial revision: 1.1 done RCS file: /cvsroot/mozilla/js/tests/js1_7/expressions/regress-346645-02.js,v done Checking in regress-346645-02.js; /cvsroot/mozilla/js/tests/js1_7/expressions/regress-346645-02.js,v <-- regress-346645-02.js initial revision: 1.1 done RCS file: /cvsroot/mozilla/js/tests/js1_7/expressions/regress-346645-03.js,v done Checking in regress-346645-03.js; /cvsroot/mozilla/js/tests/js1_7/expressions/regress-346645-03.js,v <-- regress-346645-03.js initial revision: 1.1

Verified fixed: both trunk debug builds and trunk nightly builds no longer crash on Mac.

verified fixed 1.8, 1.9 windows/mac(ppc|tel)/linux 20060803