GC issue? List.pool overwritten by allocated object

[Denis Feklushkin]

On Monday, 12 May 2025 at 15:40:01 UTC, Richard (Rikki) Andrew 
Cattermole wrote:
> On 13/05/2025 3:31 AM, Denis Feklushkin wrote:
>> Perhaps all this is the result of an error somewhere else, 
>> which results in this behavior. That is, if some my code (or 
>> third party) corrupts something that affects to allocation? 
>> But it seems that I do not do any hacks, any manipulations 
>> with pointers, etc.
>
> This is pretty heavily used code in druntime, my immediate 
> thought is what is your code doing to cause this (I didn't see 
> anything obvious)?

Yes, of course I understand perfectly well. And it seems to me 
that I am not doing anything "reprehensible".

Failure causes when code simply allocates by the "new" keyword, 
which internally calls GC's smallAlloc(). Fails on different 
points, depending on compilation options, compiled-in debug 
facilities, sanitizers, etc. And if class what allocation causes 
error manually moved into "heavy" by adding 64kB size field just 
another class allocation causes same error.

Maybe somewhere after destroy() I successfully write something 
into destroyed object field and this corrupts internal GC data? 
I'll try to remove everything destroy() calls right now

> Try using ldc's address sanitizer to see if that finds 
> something.

Nothing, sanitizer only highlights point where is pointer to pool 
is broken:

AddressSanitizer:DEADLYSIGNAL
=================================================================
==36969==ERROR: AddressSanitizer: SEGV on unknown address 
0x000100000006 (pc 0x55c3ba20eac3 bp 0x523000005500 sp 
0x7ffd7cb0fcf0 T0)
==36969==The signal is caused by a READ memory access.
     #0 0x55c3ba20eac3 in 
_D4core8internal2gc4impl12conservativeQw3Gcx10smallAllocMFNbmKmkxC8TypeInfoZPv (/home/denizzz/Dev/pukan3D/pukan+0x33fac3) (BuildId: 25246214f82ed318a32cc136c8e965179f4dcad3)

0x000100000006 is garbage value, placed by wrong allocation at 
swapchain.d:92:
s = new SyncFramesInFlight(device, commandBuffers[i]);
(if used debug configuration described in origin message):