[Issue 23978] [REG 2.103.0] ICE: EscapeBy[] is malloced, but contains GC-allocated objects

[d-bugmail at puremagic.com]

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

--- Comment #13 from Iain Buclaw <ibuclaw at gdcproject.org> ---
>From valgrind.
---
==1582870== Invalid read of size 8
==1582870==    at 0x6A33B5:
_D3dmd4root3aav15dmd_aaGetRvalueFNaNbNiPSQBnQBmQBk2AAPvZQd (aav.d:127)
==1582870==    by 0x6A36D7:
_D3dmd4root3aav__T10AssocArrayTCQBe10identifier10IdentifierTCQCh7dsymbol7DsymbolZQCl7opIndexMFNaNbNixCQDwQCsQCjZQCa
(aav.d:313)
==1582870==    by 0x512F97: DsymbolTable::lookup(Identifier const*)
(dsymbol.d:2408)
==1582870==    by 0x510B6D: ScopeDsymbol::search(Loc const&, Identifier*, int)
(dsymbol.d:1470)
==1582870==    by 0x50D2D7: StructDeclaration::search(Loc const&, Identifier*,
int) (dstruct.d:279)
==1582870==    by 0x5E8A0A:
_D3dmd6opover15search_functionFCQBe7dsymbol12ScopeDsymbolCQCe10identifier10IdentifierZCQDhQCd7Dsymbol
(opover.d:1424)
==1582870==    by 0x49DC50:
_D3dmd5clone19hasIdentityOpEqualsFCQBh9aggregate20AggregateDeclarationPSQCs6dscope5ScopeZCQDk4func15FuncDeclaration
(clone.d:462)
==1582870==    by 0x49DF98:
_D3dmd5clone13buildOpEqualsFCQBb7dstruct17StructDeclarationPSQCh6dscope5ScopeZCQCz4func15FuncDeclaration
(clone.d:519)
==1582870==    by 0x523A57: DsymbolSemanticVisitor::visit(StructDeclaration*)
(dsymbolsem.d:4790)
==1582870==    by 0x50D9E1: StructDeclaration::accept(Visitor*) (dstruct.d:502)
==1582870==    by 0x514E65: dsymbolSemantic(Dsymbol*, Scope*)
(dsymbolsem.d:131)
==1582870==    by 0x576A2B: ExpressionSemanticVisitor::visit(DeclarationExp*)
(expressionsem.d:5607)
==1582870==  Address 0x20ec8348ec8b485d is not stack'd, malloc'd or (recently)
free'd
---

Prodding this in vgdb
---
(gdb) p aa.b
$10 = (dmd.root.aav.aaA **) 0x5ebb990
(gdb) monitor who_points_at 0x5ebb990
==1582870== Searching for pointers to 0x5ebb990
==1582870== *0x5ef8600 points at 0x5ebb990
 Address 0x5ef8600 is in a rw- anonymous segment
(gdb) p aa
$11 = (dmd.root.aav.AA *) 0x5ef8600
---

There is nobody referencing the base address that was GC.realloc'd but the AA. 
So blaming xrealloc is the wrong thing here.

Next info to retrieve, look at each address between &aa.b[0] ..
&aa.b[b_length].

--