481275 - Generated Wordcode incorrect after JIT errors

Status: VERIFIED FIXED

(Tamarin Graveyard :: Virtual Machine, defect)

Description

[Rick Reitmaier]

The JIT, during verification, mutates state, which renders the generated wordcode invalid.  This is ok, as long as the JIT does not fail, but if it does and we need to fall back to the wordcode it may not be correct.

Comment 1

[Rick Reitmaier]

An example of this is if the last if () case of emitCallpropertySlot() is invoked ( i.e. jit && slotType && slotType->base == CLASS_TYPE && slotType->getCreateClassClosureProc() ) and the jit fails afterwords.

Comment 2

[Jeff Dyer]

when 478115 is fixed the word code will always look like it did when the jit was enabled before that bug is fixed. this means that this bug should be reproducable in -Dinterp mode, and not just when the jit fails.

Comment 3

[Jeff Dyer]

taking ownership

Comment 4

[Rick Reitmaier]

cross listed as watson bug 2286872.

Comment 5

[Jeff Dyer]

blocked by need for verbose output of the error, or better yet a tamarin only test case.

Comment 6

[Jeff Dyer]

Attachment: fix 1 (of N, where N > 1 most likely)

when calling an interface method using callpropvoid that verifier operand stack and the interpreter stack get out of sync (there is an extra pop of the interpreter stack introduced in e5a2c9cc1e53, mar-4). the interpreter eventually pops its way to insanity.

just to be clear, this defect was not in the code when this bug was created. so we need to apply this fix and try to repro the original problem, which occurred much later in execution of the program

Comment 7

[Jeff Dyer]

changeset 2c104dcda1cb

Comment 8

[Rick Reitmaier]

should this be marked as Resolved?

Comment 9

[Jeff Dyer]

Let's wait until the TR->TC->FR merge just to be sure.

Comment 10

[Dan Smith]

Jeff, can you confirm whether this is Resolved?

Comment 11

[Jeff Dyer]

No one has been able to repo it since the fix was merged into FR. So i guess that qualifies as Resolved.