@gireeshpunathil has investigated and the net is that there is a problem in the instructions being generated with respect to power 6 support. We've not seen it so far because our internal machines have all be power 7 so far.

@gireeshpunathil debug log

Recreatable easily in the CI system with this small code:
bash-4.3$ cat t.js

function bar() {}
for(var i=0;i<process.argv[2];i++) {
setTimeout(bar, 0);
console.log(i);
}

bash-4.3$ ./node t.js 2000
0
1
..
1676
1677
Illegal instruction (core dumped)
bash-4.3$

Investigating further.

Looks like this is a JIT bug. The crash occurs soon after we compile exports.setTimeout function:

bash-4.3$ ./node --trace_opt t.js 2000
1674
1675
[marking 0xef1fa27d <JS Function exports.setTimeout (SharedFunctionInfo ef10967d)> for recompilation, reason: hot and stable, ICs with typeinfo: 12/27 (44%), generic ICs: 0/27 (0%)]
1676
[didn't find optimized code in optimized code map for 0xef10967d ]
[compiling method 0xef1fa27d <JS Function exports.setTimeout (SharedFunctionInfo ef10967d)> using TurboFan]
[optimizing 0xef1fa27d <JS Function exports.setTimeout (SharedFunctionInfo ef10967d)> - took 6.714, 0.000, 0.000 ms]
[didn't find optimized code in optimized code map for 0xef10967d ]
[completed optimizing 0xef1fa27d <JS Function exports.setTimeout (SharedFunctionInfo ef10967d)>]
1677
Illegal instruction (core dumped)

If we skip this method from being optimize compiled, the crash is avoided:
bash-4.3$ ./node --hydrogen_filter=-exports.setTimeout --trace_opt t.js 2000
0
1
..
1117
[didn't find optimized code in optimized code map for 0xef1096f9 ]
[disabled optimization for 0xef1096f9 , reason: Optimization disabled by filter]
1118
..
2000
bash-4.3$

Next, trying to compare the code generated in good (dev) and bad (ci) machine.

The code generated seem to be the same, the notable difference is that all our dev systems are power7 while ci is hosted on power6.
Inference: Turbofan generated wrong code for setTimeout function, or not compatible for power6.
todo:

Check whether this fails in another power6 system to confirm this assumption.
Inspect the generated code and check its validity in power6 and 7.

Looks like only the first instruction in a sequence is invalid, while the rest if properly formed.
0xef3a4dc8 (???) 7c60585e Invalid opcode.
0xef3a4dcc (???) 2c030000 cmpi cr0,0x0,r3,0x0
0xef3a4dd0 (???) 40820014 bne 0xef3a4de4 (???)
0xef3a4dd4 (???) 7c651b78 mr r5,r3
0xef3a4dd8 (???) 807d0020 lwz r3,0x20(r29)
0xef3a4ddc (???) 38800000 li r4,0x0
0xef3a4de0 (???) 480000a0 b 0xef3a4e80 (???)
0xef3a4de4 (???) 80bfffe4 lwz r5,-28(r31)
0xef3a4de8 (???) 8065000b lwz r3,0xb(r5)
0xef3a4dec (???) 80c3002f lwz r6,0x2f(r3)
0xef3a4df0 (???) 90dfffe0 stw r6,-32(r31)
0xef3a4df4 (???) 7cc43378 mr r4,r6
0xef3a4df8 (???) 807d0018 lwz r3,0x18(r29)
0xef3a4dfc (???) 7cbe2b78 mr r30,r5
0xef3a4e00 (???) 7c671b78 mr r7,r3
0xef3a4e04 (???) 819c0048 lwz r12,0x48(r28)
0xef3a4e08 (???) 7d8903a6 mtctr r12
0xef3a4e0c (???) 4e800421 bctrl

...

Looks like isel (Integer Select) is the instruction which causes SIGILL in power6. Tihs instruction is decoded thus in power7:
0xef39fec8 552 7c60585e isel r3, r0, r11

Inspecting whether this is supported in power6.

bash-4.3$ hostname
dal-pax
bash-4.3$ cat foo.cpp
int main()
{
__asm("isel 0, 1, 2, 2");
}

bash-4.3$ g++ foo.cpp
.bash-4.3$ ./a.out
bash-4.3$

bash-4.3$ hostname
sovma188
bash-4.3$ ./a.out
Illegal instruction (core dumped)
bash-4.3$

Clearly, this is not supported on power6, on which CI is hosted.

Uh oh!

Uh oh!

AIX - failure in test-timers-args.js #5089

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions