Skip to content

internal/metal: Metal compute dispatch SIGSEGVs on darwin/amd64 (exposed by #171 fix) #173

Description

@dndungu

Summary

On darwin/amd64, internal/gpuapi Metal tests (e.g. TestMetal_Add) SIGSEGV
(SEGV_MAPERR) inside a real Metal dispatch. This is a pre-existing latent defect
in the hand-rolled internal/metal objc/Metal binding that was masked until
now by #171: before #172, execution crashed earlier at the dlopen/dlsym probe
(the #171 bug), so the Metal path never reached an actual objc_msgSend/Metal
dispatch. With #171 fixed, dlsym works and the test proceeds into a genuine
Metal call that faults.

Repro (darwin/amd64, Go 1.26.2)

go test -race ./internal/gpuapi/ -run TestMetal_Add

Crash stack:

SIGSEGV: segmentation violation  sigcode=1 (SEGV_MAPERR)
internal/cuda.ccall            -> syscall.syscall9
internal/metal.(*MetalLib).MsgSend        internal/metal/purego.go:149
internal/metal.(*ComputeContext).Dispatch internal/metal/compute.go:233
internal/gpuapi.(*MetalKernels).dispatchSimple internal/gpuapi/metal_kernels.go:68
internal/gpuapi.(*MetalKernels).Add             internal/gpuapi/metal_kernels.go:95
gpuapi_test.TestMetal_Add                       internal/gpuapi/metal_kernels_test.go:150

Scope / severity

Likely a bad pointer/argument marshalling into MsgSend/Dispatch (the raw
objc bridge). Needs a look at internal/metal/purego.go:149 and
internal/metal/compute.go:233 argument passing.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions