1.16.x regression: crashes/panics when YAML-stringify a large object

[nktpro]

Since 1.16.0, a deno process will crash/panic when serializing a relatively large object to YAML (via std@x.x.x/encoding/yaml.ts)

Here's a reproducer:

import { stringify as stringifyYaml } from "https://deno.land/std@0.115.1/encoding/yaml.ts";

const payload = await fetch(
  "https://gist.githubusercontent.com/nktpro/a0a626cd011c3217a0d55176d94543cf/raw/c80f9762f55bf113bd3e6c2fb62383fc8479c5ef/payload.json",
  {
    method: "GET",
    headers: {
      "Content-Type": "application/json",
    },
  },
).then((r) => r.json());

console.log("Payload", payload);

// Will crash in deno 1.16.x
console.log(stringifyYaml(payload));

Which will crash in deno 1.16.x with Trace/breakpoint trap (core dumped) output. The same snippet works fine in 1.15.x and below.

[bnoordhuis]

Thanks for the report, I'm able to reproduce.

I'm confident it's a V8 issue because it goes away when disabling the optimizing compiler with --v8-flags=--noopt.

The trap happens because the JIT-generated machine code hits an int3:

Thread 1 "deno" received signal SIGTRAP, Trace/breakpoint trap.
0x00002b4e00062a0c in ?? ()
(gdb) disassemble $rip-64,$rip+16
Dump of assembler code from 0x2b4e000629cc to 0x2b4e00062a1c:
   0x00002b4e000629cc:  push   %rbp
   0x00002b4e000629cd:  add    %al,(%rax)
   0x00002b4e000629cf:  call   *%r10
   0x00002b4e000629d2:  lea    -0x1(%rax),%r8
   0x00002b4e000629d6:  jmp    0x2b4e000628bc
   0x00002b4e000629db:  mov    0x178(%r13),%r8
   0x00002b4e000629e2:  mov    %r8,0x42e8(%r13)
   0x00002b4e000629e9:  mov    0x42e8(%r13),%r9
   0x00002b4e000629f0:  mov    %r8,0x42e8(%r13)
   0x00002b4e000629f7:  mov    -0x28(%rbp),%r8
   0x00002b4e000629fb:  mov    $0x82e0371,%r11d
   0x00002b4e00062a01:  cmp    %r11d,-0x1(%r8)
   0x00002b4e00062a05:  jne    0x2b4e00062a82
   0x00002b4e00062a0b:  int3   
=> 0x00002b4e00062a0c:  movabs $0x2b4e080cbe85,%r9
   0x00002b4e00062a16:  push   %r9
   0x00002b4e00062a18:  mov    %r8,-0x28(%rbp)
End of assembler dump.

The code falls through to the int3 because:

1. V8 reads the JS object's map word (its hidden shape) at address %r8 - 1 (-1 because it's a tagged pointer)

2. the map word should be != 0x82e0371 (caged value, not a full pointer, because of pointer compression)

3. but it's actually equal

Not sure what (3) signifies, hard to trace back, but it's probably some kind of type confusion inside V8.

I can actually get the script to complete running set $rip = <addr>; continue a few times, where <addr> is the target address of the jne instruction preceding the int3. Not a good idea, obviously, but interesting.

[bnoordhuis]

I've filed an upstream bug report: https://bugs.chromium.org/p/v8/issues/detail?id=12444

[jjallaire]

Just wanted to note that we see this crash not just with a large YAML document but also with a process that reads a large number of smaller YAML documents. It looks like the bug has been triaged and assigned (@ Priority 2) upstream so hopefully this will be resolved reasonably soon.

[bnoordhuis]

FWIW, still happens with V8 9.8.177.2.

[lucacasonato]

Fixed by https://chromium-review.googlesource.com/c/v8/v8/+/3386595. Fix should be available in Deno 1.18.

[lino-levan]

@lucacasonato I believe this issue should be closed(?)