[Issue 23978] [REG 2.103.0] ICE: dip1021 memory corruption

[d-bugmail at puremagic.com]

https://issues.dlang.org/show_bug.cgi?id=23978

--- Comment #17 from Iain Buclaw <ibuclaw at gdcproject.org> ---
(In reply to Dennis from comment #16)
> I changed it back to something more generic. My initial diagnosis was wrong
> indeed, but it still seems to be related to the `Mem.xrealloc` call in
> dmd.escape.checkMutableArguments, since changing that makes the test case
> pass.
Indeed, I still stand by my initial assessment that there are live references
to memory being marked as free by the GC.

To clarify, these are being explicitly marked free by the program, rather than
the GC scan failing to find live references.

Valgrind/vgdb confirms this at the moment in the program immediately before the
segfault occurs.

```
(gdb) monitor who_points_at 0x5ebb9c8
==1582870== Searching for pointers to 0x5ebb9c8
==1582870== *0x5eef430 points at 0x5ebb9c8
 Address 0x5eef430 is in a rw- anonymous segment
==1582870== *0xd964580 points at 0x5ebb9c8
 Address 0xd964580 is in a rw- anonymous segment
```

Expected output is for valgrind to find no references, because the memory block
is actively being used as part of a dynamic array (starting at 0x5ebb990).

We know that the memory block was first allocated for another purpose, then
subsequently marked as free'd in the GC from the initial printf debug traces of
malloc/realloc addresses.

```
Mem.xrealloc((nil), 624) = 0x5ebb990
...
Mem.xrealloc(0x5ebb990, 832) = 0x5e63000 
...
Mem.xmalloc(768) = 0x5ebb990
```

Catching the moment xrealloc is called the second time and dumping all memory
references would confirm or disprove my suspicions.

Both GC.realloc and GC.free mark the base pointer as "free" in the GC
regardless of whether there are any other live references to the memory block.

This makes the use of both Mem.xrealloc and Mem.xfree unsafe if it being used
for non-trivial data structures.

--