On Tuesday, 13 May 2025 at 10:21:12 UTC, Denis Feklushkin wrote:

I added simple debug(PRINTF) section exactly after druntime allocator. It throws error if newly allocated memory intersects with already allocated internal bucket List structures. I hope I didn't make a mistake in this code?

auto p = runLocked!(mallocNoSync, mallocTime, numMallocs)(size, bits, localAllocSize, ti);

debug(PRINTF)
{
    outer:
    foreach(List* firstList; gcx.bucket)
    {
        List* curr = firstList;
        while(curr !is null)
        {
            void* p_end = cast(ubyte*) p + localAllocSize;
            void* curr_end = cast(ubyte*) curr + List.sizeof;

            const bool notIntersects = ((p < curr && p_end < curr) || (p > curr_end && p_end > curr_end));

            if(!notIntersects)
            {
                printf("%p - allocated into bucket List value, located on %p: firstList.pool=%p curr.pool=%p\n",
                    p, curr, firstList.pool, curr.pool);

                assert(false);
                break outer;
            }

            curr = curr.next;
        }
    }
}

Druntime was built as debug version with enabled INVARIANT, MEMSTOMP and PRINTF

Then this snippet was used with compiled druntime (do not forget to replace path to new druntime in ldc2.conf):

/+ dub.sdl:
	name "issue"
+/
// How to run: dub run --single app.d

class C {}

void main()
{
    new C;
}

> dub run --single app.d --compiler=ldc2
    Starting Performing "debug" build using ldc2 for x86_64.
    Building issue ~master: building configuration [application]
     Linking issue
     Running issue
_d_newclass(ci = 0x56496398c350, app.C)
0x5649a1312c90.Gcx::addRange(0x564963985940, 0x564963994718)
GC::malloc(gcx = 0x5649a1312c90, size = 16 bits = 2, ti = app.C)
  => p = 0x7fa30e5cb000
0x7fa30e5cb000 - allocated into bucket List value, located on 0x7fa30e5cb010: firstList.pool=0x5649a1313fa0 curr.pool=0x5649a1313fa0
core.exception.AssertError@core/internal/gc/impl/conservative/gc.d(505): Assertion failure
----------------
core/runtime.d:831 [0x564963942d45]
core/lifetime.d:126 [0x56496394234c]
core/runtime.d:753 [0x564963942d0e]
core/runtime.d:773 [0x564963942640]
rt/dmain2.d:241 [0x564963920f30]
rt/deh.d:47 [0x564963949b9e]
rt/dwarfeh.d:347 [0x564963921ac2]
core/exception.d:569 [0x564963936a05]
core/exception.d:808 [0x564963936444]
core/internal/gc/impl/conservative/gc.d:505 [0x5649639502f3]
core/internal/gc/proxy.d:156 [0x56496393cf70]
core/internal/gc/impl/proto/gc.d:101 [0x5649639604fb]
core/internal/gc/proxy.d:156 [0x56496393cf70]
rt/lifetime.d:130 [0x5649639235fe]
app.d:10 [0x56496391a7af]
rt/dmain2.d:520 [0x56496392169c]
rt/dmain2.d:474 [0x5649639214b2]
rt/dmain2.d:520 [0x5649639215ba]
rt/dmain2.d:474 [0x5649639214b2]
rt/dmain2.d:545 [0x564963921372]
rt/dmain2.d:333 [0x564963921040]
/home/denizzz/ldc2_standalone/bin/../import/core/internal/entrypoint.d:42 [0x56496391a7f1]
??:? [0x7fa30e6f6ca7]
??:? __libc_start_main [0x7fa30e6f6d64]
??:? [0x56496391a6d0]
GC.fullCollect()
processing GC Marks, (nil)
rt_finalize2(p = 0x5649a1312c20)
Error Program exited with code 1

Am I making an obvious mistake somewhere?

On Tuesday, 13 May 2025 at 18:30:34 UTC, Denis Feklushkin wrote:

The intersection logic is wrong, treating adjacency as intersection. Try this: const bool intersects = (p_end > curr && p < curr_end).

On Tuesday, 13 May 2025 at 19:12:19 UTC, kinke wrote:

I changed it to this and everything worked out:

((p < curr && p_end <= curr) || (p >= curr_end && p_end >= curr_end));

It seems to be correct: all p borders should leave on same side from curr range

On Wednesday, 14 May 2025 at 06:54:42 UTC, Denis Feklushkin wrote:

The idea of ​​such check failed because List pointers to other lists sometimes are overwritten by garbage and issue just moves to curr.next access

I also see that there is no any kind of TLS sections in the libvulkan.so

But I don't understand why malloc() can give intersecting allocations in this case. Any ideas?

On Wednesday, 14 May 2025 at 08:00:06 UTC, Denis Feklushkin wrote:

The malloc function could either be thread-safe or thread-unsafe. Both are not reentrant:

Malloc operates on a global heap, and it's possible that two different invocations of malloc that happen at the same time, return the same memory block. (The 2nd malloc call should happen before an address of the chunk is fetched, but the chunk is not marked as unavailable). This violates the postcondition of malloc, so this implementation would not be re-entrant.

https://stackoverflow.com/a/3941563

Okay, I think the question can be considered closed

On Wednesday, 14 May 2025 at 09:11:13 UTC, Denis Feklushkin wrote:

However, I am still on this issue! :(

ERROR: AddressSanitizer: SEGV on unknown address 0x000100000006

I tried all 4 available TLS models: global-dynamic, local-dynamic, initial-exec, local-exec. But I didn't build druntime with these models - only resulting binary.

Valgring says that memory block, returned by malloc(), has never been allocated dynamically:

$ valgrind --tool=memcheck ./pukan
[...]
==1218062==  Address 0x100000006 is not stack'd, malloc'd or (recently) free'd

$fs_base (a-la TLS pointer reported by GDB) is 0x00007ffff7a50b40. And all other allocated and used values of my D code are lying nearby this value.

I also found that the problem with access to the 0x100000006 pointer is quite common. And, it seems, always threads-related:

https://bbs.archlinux.org/viewtopic.php?id=210363 - here I couldn't track how they solved the problem
https://github.com/gluster/glusterfs/issues/2971 - crashed while ltcmalloc library init/fini related functions are called in two different threads during a library loaded/unloaded.The process is getting crashed during access of tls variables in heap profiler api

Adding fuel to the fire is the fact that the same vulkan library works for me without (any known) problems in Danny Arends project, which uses SDL2 instead of glfw. Loading the vulkan library itself happens by the same way in both projects - linking during the build process.