debugging GC issues?

[Andrei Alexandrescu]

On 6/18/21 1:45 PM, WebFreak001 wrote:
> we have an issue in D-Scanner / libdparse that with very large files 
> memory corruption occurs. After further investigation it seems that the 
> contents of a string might have been moved as they are being reallocated.
> 
> The string is constructed 
> [here](https://github.com/dlang-community/libdparse/pull/387/files#diff-073a681f37b7ac58a75cb15be50882a5075a2ebcaa53efc4bd97cffa037ab6ddR155) 
> which calls [this 
> function](https://github.com/dlang-community/libdparse/pull/387/files#diff-a10d3a7875381b5020edcd6e55a5555e4c43c8ab1947b30b41b434ce8fa59117R512) 
> which allocates the string using an appender!string.
> 
> When first constructed the string is fine but after lots of further 
> processing of other stuff the data the string points at suddenly is no 
> longer considered allocated by the GC (maybe moved without updating the 
> struct members?) and is reused from other stuff (in my case it was 
> std.regex putting ir code in there, as shown in a GDB data watchpoint 
> that first write to it)
> 
> See 
> https://github.com/dlang-community/libdparse/pull/387#issuecomment-863442801 
> 
> 
> Does this seem like it should be possible if all code was safe? 
> (`immutable(char)[]` being moved by GC) or do you see any obvious issues 
> in this construct?

32 or 64 bits?