1321326 - Wasm ARM: Test suite failures on hardware

Status: RESOLVED DUPLICATE of bug 1283121

(Core :: JavaScript Engine: JIT, defect, P2)

Description

[Lars T Hansen [:lth]]

Machine: NVIDIA Jetson TK1 dev board (4xTegra, 2GB RAM, Ubuntu 14.04)

This is not the world's most reliable computer but the following errors seem to be repeatable:

- wasm/errors.js times out when compiled by baldr
- wasm/memory.js crashes the system (? at least hangs) when compiled by baldr
- wasm/spec/float_memory.wast.js fails when compiled by either compiler
  (see below)
- wasm/spec/memory_redundcancy.wast.js crashes the system when compiled by
  baseline

float_memory.wast.js failure:
Assertion failed: got 1.5932920260919303e-10, expected ({nan_low:2141192192})

(I know ARM's not top priority right now; this is just fallout from trying to track down another bug.)

Comment 1

[Lars T Hansen [:lth]]

Both compilers crash on wasm/spec/memory_redundancy.wast.js because we do not support unaligned-access signals, this is bug 1283121.

Comment 2

[Lars T Hansen [:lth]]

Both compilers crash on wasm/spec/float_memory.wast.js because the unaligned-access signal handler (seeing a floating-point load) replaces the faulting PC with the same PC, so we iloop.  I haven't dug deeply into the logic in the signal handler, but this is the effect.

Comment 3

[Lars T Hansen [:lth]]

Both compilers crash on wasm/memory.js for the same reason as comment 2.

Comment 4

[Lars T Hansen [:lth]]

And as for wasm/errors.js, it hangs for the same reason as in comment 2 and comment 3, but it is arguably a different bug because all these accesses are out of bounds and bounds checking should "just work".  It could be, as Benjamin said on IRC, that it can be hard for the trap handler to figure out what's going on because it has imprecise information.

Will file a separate bug for this, but also annotate the general signal handler bug.

Comment 5

[Lars T Hansen [:lth]]

Actually it's all signal handling, let's not multiply entities beyond necessity.