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)?

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

Otherwise try dividing and conquering to find what triggers it down to the statement.

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):

On 13/05/2025 6:22 AM, Denis Feklushkin wrote:
>     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):

This is useful information, now you can minify your code to what causes it.

I suggest throwing dustmite at it, and looking for that segfault.

https://github.com/CyberShadow/DustMite

On Monday, 12 May 2025 at 18:22:16 UTC, Denis Feklushkin wrote:

> 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

Removed all destroy() calls - nothing changed

On 13/05/2025 10:08 PM, Denis Feklushkin wrote:
> dustmite needs a lot of time - I launched it but I'm still waiting

What I normally do is help dustmite.

Run it for a little bit, dup the file system, remove some cycles or dependent usage of a variable, run it again.

It can't always break chains, so it needs a bit of help.

On Tuesday, 13 May 2025 at 10:14:17 UTC, Richard (Rikki) Andrew Cattermole wrote:
> On 13/05/2025 10:08 PM, Denis Feklushkin wrote:
>> dustmite needs a lot of time - I launched it but I'm still waiting
>
> What I normally do is help dustmite.
>
> Run it for a little bit, dup the file system, remove some cycles or dependent usage of a variable, run it again.
>
> It can't always break chains, so it needs a bit of help.

Yes, I already did some for this.

At first (for the whole night) I decided to launch "dub dustmite", which (it seems) works only over whole sources with dependencies, and it was too big amount of work