Last Comment Bug 655508 - TI+JM: Assertion failure: obj, at jsval.h:514
: TI+JM: Assertion failure: obj, at jsval.h:514
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: unspecified
: x86 All
-- normal (vote)
: ---
Assigned To: general
: Jason Orendorff [:jorendorff]
Depends on:
Blocks: infer-regress
  Show dependency treegraph
Reported: 2011-05-07 11:23 PDT by Jan de Mooij [:jandem]
Modified: 2011-05-09 13:10 PDT (History)
4 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

Testcase (381 bytes, application/x-javascript)
2011-05-07 11:23 PDT, Jan de Mooij [:jandem]
no flags Details

Description User image Jan de Mooij [:jandem] 2011-05-07 11:23:28 PDT
Created attachment 530863 [details]

$ ./js -n -m -a test.js
Assertion failure: obj, at jsval.h:514

Revision e09e209d988e, 32-bit OS X.
Comment 1 User image Christian Holler (:decoder) 2011-05-07 11:37:55 PDT
This issue is 32 bit only.

I reduced the testcase only slightly:

for (var i = 0;;) switch (3) {
    function () {
        var x;
        (function () {})() && false;
        x = undefined;
        try {
        } catch (e) {}
    function () {
        [typeof loopa1]
Comment 2 User image Brian Hackett (:bhackett) 2011-05-09 13:10:44 PDT
Funny issue, for local variables with no use-before-def we don't write an undefined value but mark the local as synced at script entry (so we don't try to write the value out later; in any case that initial value won't be observed).  The problem is that if the variable is then written with a value known to be undefined (which could be subsequently observed), we see that the old type is also undefined and decide the new type doesn't need to be written out, ending up with the torn value seen here.  This fix just always syncs types after writing undefined to locals, presumably a rare operation.

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