Async MySQL extension creating invalid Map in HHVM 4.80

[ssandler]

Describe the bug
Experiencing a significant rate of segfaults after upgrading to HHVM 4.80

Standalone code, or other way to reproduce the problem

This is reproducing for us at a rate of a few times per hour on a host running this code, but we have not found a standalone repro:

// $result is an AsyncMysqlQueryResult
$rows = varray[];
foreach ($result->mapRowsTyped() as $row) {
	$rows[] = $row->toDArray();
}
return $rows;

The PHP stack trace points to the line on which we do $row->toDArray(), and the C++ stacks from gdb look like this:

#0  raise (sig=<optimized out>) at ../sysdeps/unix/sysv/linux/raise.c:51
#1  0x0000562fddce4dc9 in HPHP::bt_handler (sigin=<optimized out>, info=<optimized out>) at /build/hhvm/hphp/runtime/base/crash-reporter.cpp:270
#2  <signal handler called>
#3  HPHP::BespokeArray::IterAdvance (ad=0x7f8942faa140, pos=140227510968640) at /build/hhvm/hphp/runtime/base/bespoke-array.cpp:175
#4  0x0000562fddc386e1 in HPHP::ArrayData::iter_begin (this=0x7f8942faa140) at /build/hhvm/hphp/runtime/base/array-data-defs.h:168
#5  HPHP::ArrayIter::setArrayData (ad=0x7f8942faa140, this=0x7f89b9ffb0b0) at /build/hhvm/hphp/runtime/base/array-iterator.h:197
#6  HPHP::ArrayIter::arrInit<true> (this=0x7f89b9ffb0b0, arr=0x7f8942faa140) at /build/hhvm/hphp/runtime/base/array-iterator.cpp:86
#7  0x0000562fddc3292e in HPHP::IterateKV<HPHP::ArrayData::toDArray(bool)::<lambda(auto:58, auto:59)>, false> (arrFn=..., adata=0x7f8942faa140) at /build/hhvm/hphp/runtime/base/array-iterator.h:354
#8  HPHP::IterateKVNoInc<HPHP::ArrayData::toDArray(bool)::<lambda(auto:58, auto:59)> > (arrFn=..., adata=0x7f8942faa140) at /build/hhvm/hphp/runtime/base/array-iterator.h:364
#9  HPHP::ArrayData::toDArray (this=0x7f8942faa140, copy=copy@entry=true) at /build/hhvm/hphp/runtime/base/array-data.cpp:1112
#10 0x0000562fdebf35c5 in HPHP::Array::toDArray (this=0x7f89b9ffb120) at /build/hhvm/hphp/runtime/base/type-array.h:202
#11 HPHP::HashCollection::toDArray (this=0x7f893cfd8250) at /build/hhvm/hphp/runtime/ext/collections/hash-collection.cpp:106
#12 0x0000562fe3c6437a in ?? ()
#13 0x00007f8a599ff710 in ?? ()
#14 0x00007f8940b519c0 in ?? ()
#15 0x0000562fe3c00018 in ?? ()
#16 0x00007f893c767ca0 in ?? ()
#17 0x0000000000000001 in ?? ()
#18 0x00007f89b97f9d28 in ?? ()
#19 0x00007f8940a941b0 in ?? ()
#20 0x0000562fe3c5e84b in ?? ()
#21 0x00007f89b9ffb1b0 in ?? ()
#22 0x0000562fde333683 in HPHP::jit::enterTC (start=0x7f893cfd8250 "\002") at /build/hhvm/hphp/runtime/vm/jit/enter-tc.cpp:68

Environment

• Operating system
  Ubuntu 18.04
• Installation method
  Built from source
• HHVM Version

HipHop VM 4.80.6 (rel)
Compiler: remotes/origin/4.80.6-slack-0-g0d1cc2f708e29ce3bffe6bd33ca27ad87d908d04
Repo schema: 368419f649dc5856326d84e9ed95fdef2fbad95f

[fredemmott]

• issue is when iterating, not specificially when creating the darray
• gdb segfaults when attempting to inspect the map

[fredemmott]

This might be a symptom of #8861; cores for this issue are reportedly extremely large, indicating it might be an issue handling large amounts of data

[fredemmott]

This is either a bug in the GC, or something (maybe #8861) is confusing the GC. Confirmed that:

• heap object kind is hole
• padded with 0x8a (octal 212)
• was running with GC quarantine enabled, which makes the GC turn memory into 0x8a-padded holes instead of freeing