Note: There are a few cases of duplicates in user autocompletion which are being worked on.

"Assertion failure: caller->fun()->isHeavyweight(),"

RESOLVED FIXED

Status

()

Core
JavaScript Engine
--
critical
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: gkw, Unassigned)

Tracking

(Blocks: 1 bug, {assertion, regression, testcase})

Trunk
assertion, regression, testcase
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite ?

Firefox Tracking Flags

(blocking-fx ?)

Details

Attachments

(1 attachment)

(Reporter)

Description

6 years ago
Math.p = 0
f = (function () {
    return ((eval("") for ({} in Math)))
})
for (i in f()) {}

asserts js debug shell on TM changeset 5152bdff3c9c without -m nor -j at Assertion failure: caller->fun()->isHeavyweight()

This was found using a combination of jsfunfuzz and jandem's method fuzzer.
(Reporter)

Comment 1

6 years ago
Created attachment 522223 [details]
stack
(Reporter)

Comment 2

6 years ago
autoBisect shows this is probably related to the following changeset:

The first bad revision is:
changeset:   63366:dbb123c798c8
user:        Luke Wagner
date:        Mon Mar 14 11:30:36 2011 -0700
summary:     Bug 636296 - Change meaning of JSStackFrame::hasCallObj to be more sane (r=waldo)
Blocks: 636296
OS: Windows 7 → All
Hardware: x86 → All

Comment 3

6 years ago
Ah ha.  Bug 636296 strengthened this assertion (http://hg.mozilla.org/tracemonkey/rev/dbb123c798c8#l9.12 .

So either:
 (1) the new assertion is overzealous (NB: the meaning of hasCallObj has changed, which is why I touched this)
 (2) there is a bug in the heavyweight-marking of generator expressions

I was under the impression that the implication
  contains a direct eval ==> is heavyweight
held, so it seems like (2).  Anyone here familiar with generator expression parser magic?

Updated

6 years ago
No longer blocks: 636296
(In reply to comment #3)
> Ah ha.  Bug 636296 strengthened this assertion
> (http://hg.mozilla.org/tracemonkey/rev/dbb123c798c8#l9.12 .
> 
> So either:
>  (1) the new assertion is overzealous (NB: the meaning of hasCallObj has
> changed, which is why I touched this)
>  (2) there is a bug in the heavyweight-marking of generator expressions
> 
> I was under the impression that the implication
>   contains a direct eval ==> is heavyweight
> held, so it seems like (2).  Anyone here familiar with generator expression
> parser magic?

I agree with the analysis. Also, dis() applied to a test case where this code is wrapped in a function shows that the generation function is not marked heavyweight.
(Reporter)

Updated

6 years ago
blocking-fx: --- → ?
(Reporter)

Comment 5

6 years ago
Comment 0 no longer asserts after the following fix landed on JM:

autoBisect shows this is probably related to the following changeset:

The first good revision is:
changeset:   71037:cbf05c26053e
user:        Brian Hackett
date:        Tue Jun 07 16:33:25 2011 -0700
summary:     [INFER] Fix no-op propagation of deoptimization flags for array comprehensions, bug 660538.

Thus, the assertion is likely to be fixed when TI lands on mozilla-central some weeks later.

(it still asserts in mozilla-inbound changeset 223d4f4bd252, tip as of now)
(Reporter)

Updated

6 years ago
Flags: in-testsuite?
(Reporter)

Comment 6

6 years ago
Fixed by landing of TI on m-i/m-c:

http://hg.mozilla.org/mozilla-central/rev/b61af4d7dc7c (last TI changeset on TI branch)
http://hg.mozilla.org/mozilla-central/rev/31b79d4e90f4 (merge of last green m-i changeset to m-c)
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.