637403 - JM: Assertion failure: stubsGenerated < MAX_PIC_STUBS, at ../methodjit/PolyIC.cpp:1974

Status: RESOLVED WORKSFORME

(Core :: JavaScript Engine, defect)

Description

[Jan de Mooij [:jandem]]

--
var o1 = untrap;
var o2 = {};
o2.__defineGetter__('x', o1);
o2.x();
--
Asserts in debug mode:
32-bit:

$ ./js -a -m -d test.js
Assertion failure: stubsGenerated < MAX_PIC_STUBS, at ../methodjit/PolyIC.cpp:1974

64-bit:
Assertion failure: (strBits >> JSVAL_TAG_SHIFT) == 0, at ../jsval.h:622

Marking s-s because (especially) the 64-bit assertion seems weird, please unmark if this turns out to be shell only.

Comment 1

[Jan de Mooij [:jandem]]

Attachment: Stack trace (64-bit)

A value of 0xdadadadadadadada is passed to setString...

Comment 2

[David Mandelin [:dmandelin]]

Looks like something for valgrind.

Comment 3

[David Mandelin [:dmandelin]]

Here is the cause:

var o1 = untrap;
var o2 = {};
o2.__defineGetter__('x', o1);
o2.x();

In the last statement we call into ic::CallProp, which takes a pointer to a PICInfo as input. First, it does the getprop for 'x'. This calls |untrap|, which recompiles the script and frees all its structures. Then it uses the PICInfo pointer to try to do stuff with the PIC. But that now points to freed memory, and bad things ensue.

We probably don't need to fix this right now, we should just be sure to pick it up when we redo debug mode.

Comment 4

[Daniel Veditz [:dveditz]]

(In reply to comment #3)
> Then it uses the PICInfo pointer to try to do stuff with the PIC. But
> that now points to freed memory, and bad things ensue.
> 
> We probably don't need to fix this right now, we should just be sure to pick it
> up when we redo debug mode.

I'm having trouble reconciling the first paragraph and the sg:critical rating on the bug, with the second comment. Is this a debug-only problem? If so is it really a security problem?

Comment 5

[Jan de Mooij [:jandem]]

Seems debug-mode only and therefore not sg:critical.

Comment 6

[David Mandelin [:dmandelin]]

After further discussion, we realized that this test case is shell-only. So this might not be sg:critical. The only way it would be is if there is a reliable way to trigger recompilation from a property getter, but I don't think the browser allows direct interaction with breakpoints via script.

Comment 7

[Daniel Veditz [:dveditz]]

OK, sg:moderate -- IF you can get a developer to use a debugger and interact with bad code in very specific ways it can crash dangerously, but minimal risk in real life.

Comment 8

[Jan de Mooij [:jandem]]

JM was removed, this is debug-mode only and probably got fixed a long time ago.