httpx 1.9.0 SIGSEGV on macOS Tahoe arm64 — go-m1cpu@v0.1.6 cgo init crash

[cory-kantar]

Summary

httpx v1.9.0 (brew-installed, Apple Silicon) consistently SIGSEGVs at startup on macOS 26.4.1 (Tahoe). The crash is deterministic — happens on every invocation including httpx -version — and the stack trace points at the go-m1cpu library's cgo init.

Environment

• httpx version: 1.9.0 (brew-installed)
• OS: macOS 26.4.1 (Tahoe)
• Arch: arm64 (Apple Silicon)
• Binary: /opt/homebrew/bin/httpx (verified Mach-O 64-bit executable arm64)
• Quarantine attrs: none (only com.apple.provenance)
• brew formula version: 1.9.0 (latest as of 2026-05-20; matches installed)

Reproducer

$ /opt/homebrew/bin/httpx -version
SIGSEGV: segmentation violation
PC=0x18904f1a8 m=0 sigcode=2 addr=0x0
signal arrived during cgo execution

goroutine 1 gp=0x7483d8e161e0 m=0 mp=0x103d35a80 [syscall, locked to thread]:
runtime.cgocall(0x10181c114, 0x7483d8ecee08)
	runtime/cgocall.go:167 +0x44 fp=0x7483d8ecedd0 sp=0x7483d8eced90 pc=0x100a45c14
github.com/shoenig/go-m1cpu._Cfunc_initialize()
	_cgo_gotypes.go:138 +0x2c fp=0x7483d8ecee00 sp=0x7483d8ecedd0 pc=0x10123ee8c
github.com/shoenig/go-m1cpu.init.0()
	github.com/shoenig/go-m1cpu@v0.1.6/cpu.go:148 +0x1c fp=0x7483d8ecee10 sp=0x7483d8ecee00 pc=0x10123eecc
runtime.doInit1(0x103a6e3a0)
	runtime/proc.go:8103 +0xc4 fp=0x7483d8ecef30 sp=0x7483d8ecee10 pc=0x100a235e4
runtime.doInit(...)
	runtime/proc.go:8070
runtime.main()
	runtime/proc.go:258 +0x244 fp=0x7483d8ecefd0 sp=0x7483d8ecef30 pc=0x100a13624

Root cause

The crash is in github.com/shoenig/go-m1cpu@v0.1.6's init() function, specifically the cgo-wrapped initialize() C call. The go-m1cpu library detects Apple Silicon CPU capabilities via sysctlbyname calls. Apple changed sysctl semantics in macOS Tahoe, breaking the v0.1.6 codepath; upstream go-m1cpu shipped a fix in v0.1.7 (2025-09-16) and bumped to v0.2.0 / v0.2.1 since.

The httpx repo's go.mod (main branch) still pins github.com/shoenig/go-m1cpu v0.1.6 // indirect — the v0.1.7+ fix hasn't propagated. The transitive dependency is most likely via github.com/shirou/gopsutil/v3, which httpx pulls in through several intermediate dependencies.

Confirmed unaffected

• httpx 1.9.0 on Linux x86_64 — no crash
• Docker image projectdiscovery/httpx:latest — no crash (Linux container, no macOS sysctl path)

Suggested fix

Bump go-m1cpu to v0.1.7 or later. If the dep is fully transitive (no direct usage in httpx), a go mod edit -replace=github.com/shoenig/go-m1cpu=github.com/shoenig/go-m1cpu@v0.2.1 plus go mod tidy should propagate. Otherwise upgrading gopsutil (and any other ancestor) to a version that already pulls v0.1.7+ also works.

The same crash likely affects every ProjectDiscovery Go tool whose dependency tree pulls go-m1cpu@v0.1.6 (subfinder, naabu, nuclei, katana) on macOS Tahoe — at least nuclei + katana don't crash today, suggesting either they don't pull the same dep or my host hasn't exercised the crash path on those binaries. Worth a go mod why github.com/shoenig/go-m1cpu audit across the project family.

Workaround for affected operators

• Use the Docker image (docker run --rm projectdiscovery/httpx:latest) until the host binary is rebuilt against go-m1cpu v0.1.7+
• Or stay on macOS Sequoia or earlier where the v0.1.6 codepath still works

Filing this from the operator perspective; happy to test a candidate build against macOS Tahoe arm64 if it helps speed the validation.

[chapimenge3]

Additional information (M5 Pro + macOS Tahoe 26.4.1)

I am also experiencing the exact same crash on httpx -version (and any command).

Environment:

• Device: 14-inch MacBook Pro with Apple M5 Pro chip
• OS: macOS Tahoe 26.4.1
• Go version: go1.26.2 darwin/arm64

Crash details:

Immediate SIGSEGV in github.com/shoenig/go-m1cpu@v0.1.6 during _Cfunc_initialize() (cgo execution)

➜  ~ httpx -version                                                                     
SIGSEGV: segmentation violation
PC=0x185dab1a8 m=0 sigcode=2 addr=0x0
signal arrived during cgo execution

goroutine 1 gp=0x275d9d1fe1e0 m=0 mp=0x10812db00 [syscall, locked to thread]:
runtime.cgocall(0x105c044d4, 0x275d9d2aee08)
	/usr/local/go/src/runtime/cgocall.go:167 +0x44 fp=0x275d9d2aedd0 sp=0x275d9d2aed90 pc=0x104e2d954
github.com/shoenig/go-m1cpu._Cfunc_initialize()
	_cgo_gotypes.go:138 +0x2c fp=0x275d9d2aee00 sp=0x275d9d2aedd0 pc=0x105626dfc
github.com/shoenig/go-m1cpu.init.0()
	/Users/chapi/go/pkg/mod/github.com/shoenig/go-m1cpu@v0.1.6/cpu.go:148 +0x1c fp=0x275d9d2aee10 sp=0x275d9d2aee00 pc=0x105626e3c
runtime.doInit1(0x107e66400)
	/usr/local/go/src/runtime/proc.go:8103 +0xc4 fp=0x275d9d2aef30 sp=0x275d9d2aee10 pc=0x104e0b324
runtime.doInit(...)
	/usr/local/go/src/runtime/proc.go:8070
runtime.main()
	/usr/local/go/src/runtime/proc.go:258 +0x244 fp=0x275d9d2aefd0 sp=0x275d9d2aef30 pc=0x104dfb364
runtime.goexit({})
	/usr/local/go/src/runtime/asm_arm64.s:1447 +0x4 fp=0x275d9d2aefd0 sp=0x275d9d2aefd0 pc=0x104e38ce4

Happens before any real execution (even on -version)

This appears to be the well-known incompatibility between go-m1cpu v0.1.6 (and v0.1.7) and the new M5 series chips on macOS Tahoe.

The library has already been fixed in go-m1cpu v0.2.0+ (and some projects like NetBird have already merged the update).

Would it be possible to bump the go-m1cpu dependency in httpx?

[dogancanbakir]

Thanks for letting us know friends! The dependency we talk about it here is coming from the other PD tools, that means this needs to be fixed in those tools/libs which is what I do right now. That also means, the fix ships in the next release. I'll keep this issue open till those tools/libs bumped in httpx.