Problem with GC and address/leak sanitizer

[Steven Schveighoffer]

On Saturday, 15 February 2025 at 23:31:42 UTC, Luís Marques wrote:
> I have a program where the GC *seems* to be overwriting memory 
> still in use and corrupting data.

Do I understand that this corruption is happening only with 
address sanitizer turned on?

I don't see any red flags here, though I'm assuming a lot of 
these weird random things you are doing (like appending a space 
to a string every loop) are essential to making the thing fail? 
It's possible these are tickling GC patterns that cause problems, 
or it's possible it's tickling bugs in code generation that might 
prevent the GC from seeing memory!

Writing to the "check" field might be because a gc cycle ran, and 
that item was incorrectly collected, and now the gc is writing to 
it because it thinks that data is fair game to use.

The writing is probably not the problem, the problem is the 
previous collection of that data.

I have learned a lot of tricks when implementing the new GC, and 
when faced with problems like this, it's super-difficult to 
figure out how to properly find the problem.

One technique I used is to fork after scanning, but before 
collection, and put that forked process to sleep. If the failure 
happens, then I can gdb into the forked process and see what 
state the GC was in, including the entire graph of memory, and I 
could see how a piece of memory is or isn't referenced.

This is a tedious process, and requires a lot of knowledge and 
patience. If this is indeed a problem with the GC, it's going to 
be tough to track down. If it's a problem with the codegen, then 
probably also difficult, but this function is small enough, that 
maybe someone can look at the assembly and verify that it's doing 
the right thing? I don't know.