DispatchData.init(bytesNoCopy:deallocator:) with anything other than Deallocator.custom crashes with SEGV_ACCERR

[dblsaiko]

On Linux, Gentoo amd64.

Reproducer:

import Foundation

let blockAllocationSize = 1024768
let p = malloc(blockAllocationSize)!
let uninitializedBuffer = DispatchData(
        bytesNoCopy: .init(start: p, count: blockAllocationSize), deallocator: .free)

print(uninitializedBuffer.isEmpty)

Replacing the .free with .custom(nil, { free(p) } makes the program run correctly.

I assume this is actually a bug around @convention(block) when running without Objective-C but submitting it here first.

           PID: 1898768 (test)
           TID: 1898768 (test)
           UID: 1000 (saiko)
           GID: 100 (users)
        Signal: 11 (SEGV) si_code: SEGV_ACCERR
     Timestamp: Wed 2026-07-01 17:10:44 CEST (4s ago)
  Command Line: ./test
    Executable: /Users/saiko/test
 Control Group: /user.slice/user-1000.slice/user@1000.service/app.slice/app-org.kde.konsole-1876058.scope/tab(1876070).scope
          Unit: user@1000.service
     User Unit: app-org.kde.konsole-1876058.scope
         Slice: user-1000.slice
     Owner UID: 1000 (saiko)
       Boot ID: b2908daea814494bb4ced9cff518b431
    Machine ID: 9cea39f4ff0243689dd77d344c5fe60c
      Hostname: carcosa
       Storage: /var/lib/systemd/coredump/core.test.1000.b2908daea814494bb4ced9cff518b431.1898768.1782918644000000.zst (present)
  Size on Disk: 1M
       Message: Process 1898768 (test) of user 1000 dumped core.
                
                Module libunwind.so.1 without build-id.
                Module libc++abi.so.1 without build-id.
                Module libc++.so.1 without build-id.
                Stack trace of thread 1898768:
                #0  0x00007f5ae8ed5128 swift_retain (libswiftCore.so + 0x4d5128)
                #1  0x00007f5ae889a3c5 $s8Dispatch0A4DataV11bytesNoCopy11deallocatorACSW_AC11DeallocatorOtcfC (libswiftDispatch.so + 0x1d3c5)
                #2  0x000055e6af28c406 main (test + 0x2406)
                #3  0x00007f5ae76845fe __libc_start_call_main (libc.so.6 + 0x275fe)
                #4  0x00007f5ae768471b __libc_start_main_impl (libc.so.6 + 0x2771b)
                #5  0x000055e6af28bf05 _start (test + 0x1f05)
                ELF object binary architecture: AMD x86-64

[compnerd]

This feels like user error - malloc is invalid for use. If you use malloc, you must provide a custom deallocation routine (which calls free). There is no guarantee about the memory allocator that is used and the memory domains must match to avoid the cross-domain free.

CC: @akmorrison

[dblsaiko]

Oh, what is .free then used for? It sounds to me like it would call the normal C free() that pairs with malloc(). Besides, it crashes in the constructor, not in the deallocator.

[dblsaiko]

Yes, that's exactly what it's used for, it should work, as per the equivelant C API:

/*!
 * @const DISPATCH_DATA_DESTRUCTOR_FREE
 * @discussion The destructor for dispatch data objects created from a malloc'd
 * buffer. Used at data object creation to indicate that the supplied buffer
 * was allocated by the malloc() family and should be destroyed with free(3).
 */
#define DISPATCH_DATA_DESTRUCTOR_FREE (_dispatch_data_destructor_free)

It works as expected on macOS.