699161 - Intermittent JIT failure with equality testing of float values

Status: VERIFIED FIXED

(Tamarin Graveyard :: Baseline JIT (CodegenLIR), defect)

Description

[Brent Baker]

There are a handfull of equality tests in floatOperations.as in the "=== float op Any (float) ===" section, comparing float with float. I have tried to narrow this testcase down but it 'appears' that if I remove too much code that is not related to these tests I am not able to get this issue to happen.

./runtests.py --vmargs="-Ojit" as3/Types/Float/floatOperations.as

   >> >> GT !FAILED!  = 0 FAILED! expected: 1
   >> >> GTE !FAILED!  = 1 FAILED! expected: 0
   >> >> LT !FAILED!  = 0 FAILED! expected: 1
   >> >> LTE !FAILED!  = 1 FAILED! expected: 0
   >> EQ !FAILED!  = 0 FAILED! expected: 1
   >> SEQ !FAILED!  = 0 FAILED! expected: 1
   >> NEQ !FAILED!  = 1 FAILED! expected: 0
   >> sneq !FAILED!  = 1 FAILED! expected: 0


I have seen this happen on mac os x 64bit and on linux 64bit. It may take 30+ iterations before you see this failure, although it could happen on the first run if you are lucky :) or is that unlucky...

Comment 1

[Virgil Palanciuc]

I could repro in Debug-Debugger build, 32bits,  OSx (in Release-Debugger, both 32-bit and 64-bit, doesn't reproduce in a few thousand iterations). My results are somehow different:

FltAnyOps SUB !FAILED!  = 0 FAILED! expected: 28.260000228881836
FltAnyOps MUL !FAILED!  = 985.9599609375 FAILED! expected: 98.59600067138672
FltAnyOps DIV !FAILED!  = 1 FAILED! expected: 10
FltAnyOps MOD !FAILED!  = 0 FAILED! expected: 3.140000104904175
FltAnyOps UMINUS !FAILED!  = -31.399999618530273 FAILED! expected: -3.140000104904175
FltAnyOps UPLUS !FAILED!  = 31.399999618530273 FAILED! expected: 3.140000104904175
>> FltAnyOps GT !FAILED!  = 1 FAILED! expected: 0
>> FltAnyOps GTE !FAILED!  = 0 FAILED! expected: 1
>> FltAnyOps LT !FAILED!  = 1 FAILED! expected: 0
>> FltAnyOps LTE !FAILED!  = 0 FAILED! expected: 1
FltAnyOps EQ !FAILED!  = 1 FAILED! expected: 0
>> FltAnyOps EQ !FAILED!  = 0 FAILED! expected: 1
FltAnyOps SEQ !FAILED!  = 1 FAILED! expected: 0
>> FltAnyOps SEQ !FAILED!  = 0 FAILED! expected: 1
FltAnyOps NEQ !FAILED!  = 0 FAILED! expected: 1
>> FltAnyOps NEQ !FAILED!  = 1 FAILED! expected: 0
FltAnyOps SNEQ !FAILED!  = 0 FAILED! expected: 1
>> FltAnyOps SNEQ !FAILED!  = 1 FAILED! expected: 0

(in one run I got the faiures starting with "MUL" -i.e. "SUB" passed...)

Comment 2

[Lars T Hansen]

Using -Dgreedy on a Mac DD 32-bit build provokes a bunch of failures on the first try.

Comment 3

[Lars T Hansen]

And also on a Mac R 32-bit build.

Comment 4

[Lars T Hansen]

Attachment: Simpler test case

This is enough to provoke failures on the first attempt with -Dgreedy on Release and Debug-Debugger; the failure sets are mostly nonoverlapping in the two cases.

Release:

FltAnyOps GTE
FltAnyOps LT
FltAnyOps LTE
FltAnyOps EQ
FltAnyOps EQ
FltAnyOps SEQ
FltAnyOps SEQ
FltAnyOps NEQ
FltAnyOps NEQ
FltAnyOps SNEQ
FltAnyOps SNEQ

Debug-debugger:

FltAnyOps ADD
FltAnyOps SUB
FltAnyOps MUL
FltAnyOps DIV
FltAnyOps MOD
FltAnyOps UMINUS
FltAnyOps UPLUS
FltAnyOps LTE
FltAnyOps NEQ
FltAnyOps SNEQ

Comment 5

[Lars T Hansen]

It is virtually guaranteed that this is related to interface calls, since if I remove the IFloatOps annotation on the "obj" variable then the errors go away (in Release mode so far, still waiting for DD to finish).

Comment 6

[Lars T Hansen]

Ditto in the DD build: no failures with the annotation commented out.

Comment 7

[Brent Baker]

Attachment: Another simple testcase

Another testcase: (cribbed from Float/flt_6_3_10.as)

64bit release-debugger OSX:
   u:          2.1413118839263916
   flt:        2.1413118839263916
   o:          3.1413118839263916
   flt_plus_1: 4.1413116455078125

64bit release-debugger OSX with -Dgreedy:
   u:          2.1413118839263916
   flt:        2.1413118839263916
   o:          0
   flt_plus_1: 2.4026954939393893e-38

Comment 8

[Brent Baker]

(In reply to Brent Baker from comment #7)
> Created attachment 572807 [details]
> Another simple testcase

I actually get different results with this test based on the following combinations:

No switches (hybrid mode)
   o:          3.1413118839263916
   flt_plus_1: 4.1413116455078125

-Dgreedy -Dinterp 
   o:          0
   flt_plus_1: 2.4026954939393893e-38

-Dgreedy -Ojit
   o:          2.403771691159991e-38
   flt_plus_1: 2.4026932518618464e-38

Comment 9

[Lars T Hansen]

That's normal; heap dynamics are essentially chaotic (at least in an informal way).  Virgil's assumption has been that we're interpreting a float as a pointer in one context and thus shifting heap content would play a role.

Comment 10

[Virgil Palanciuc]

Fixed (by Lars :) ) in changeset 6812:164a8a012b2a.

Comment 11

[Virgil Palanciuc]

In case someone encounters something similar in the future: besides the MMgc folder, there is GC work happening in AvmCore (e.g. atomWriteBarrier), and in Traits.cpp (e.g. Traits::traceSlotsFromBitmap). I missed the "Traits.cpp" part, so the GC was not properly marking the used bibop pages

Comment 12

[Lars T Hansen]

At one point I tried moving the traits code into the GC, but the change did not stick.  Might be a good idea to rethink that.

Comment 13

[Brent Baker]

Verified that the failure is no longer reproducible in changeset 6813:e7f048b5fdf2