Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

close

Closed
  • Is something wrong?
#107 2 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 2 days

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
35/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
rust
Domain
backend

Research direction

Start by inspecting the NVMTLComputeCommandEncoder deallocation path and its stored ivars; the issue names the crashing -[NVMTLComputeCommandEncoder .cxx_destruct] frame but no source file or test. Trace ownership of the bindings dictionary and other released objects, then reproduce through the Vision face detector or Espresso/MPS workload. Done means the encoder no longer crashes during teardown across the reported workload.

Written by the indexing model from the issue text.

Description

What happens

mediaanalysisd dies with EXC_BAD_ACCESS / SIGSEGV inside -[NVMTLComputeCommandEncoder .cxx_destruct].
Seven reports between 10-09 03:29 and 10-11 04:14. Every one is reached from Espresso/MPS neural-network work —
Vision's face detector (VNShotflowNetwork) and Espresso convolution kernels.

This is a different crash from #50. #50 is an assert() in NVK reached from a draw; this one is a bad memory
access in our own dealloc path, and no assert is involved.

Two shapes, same frame

Shape A — 5 reports, thread queue comm_safety_handler, fault address 0x20:

 0  libobjc.A.dylib      objc_release
 1  CoreFoundation       cow_cleanup
 2  CoreFoundation       -[__NSDictionaryM dealloc]
 3  NVMTLDriver          -[NVMTLComputeCommandEncoder .cxx_destruct]
 4  libobjc.A.dylib      object_cxxDestructFromClass(objc_object*, objc_class*)
 5  libobjc.A.dylib      objc_destructInstance_nonnull_realized(objc_object*)
 6  libobjc.A.dylib      _objc_rootDealloc
 7  MPSCore
 8  MPSNeuralNetwork
11  Espresso             Espresso::MPSEngine::mps_convolution_kernel::__launch(...)
16  Espresso             Espresso::net::__forward(...)
17  EspressoLight        EspressoLight::espresso_plan::dispatch_task_on_compute_batch(...)

Shape B — 2 reports, thread queue com.apple.espresso.mainqueue, fault address 0x0:

 0  libobjc.A.dylib      objc_msgSend
 1  NVMTLDriver          -[NVMTLComputeCommandEncoder .cxx_destruct]
 2  libobjc.A.dylib      object_cxxDestructFromClass(objc_object*, objc_class*)
 3  libobjc.A.dylib      objc_destructInstance_nonnull_realized(objc_object*)
 4  libobjc.A.dylib      _objc_rootDealloc
 5  Espresso             Espresso::MPSEngine::blob_container::__copy_to_host(...)
 6  EspressoLight        EspressoLight::espresso_plan::__copy_outputs(...)
 8  EspressoLight        EspressoLight::espresso_plan::execute_sync()
 9  EspressoLight        espresso_plan_execute_sync
10  Vision               -[VNShotflowNetwork runNetwork:inputIsBGR:]
14  Vision               ...ObjectDetector_DCNFaceDetector_v2::detectFacesInImageBufferInternal(...)
What the two together say

In A, .cxx_destruct releases a dictionary ivar; cow_cleanup walks that dictionary and releasing an entry
faults at +0x20. In B, .cxx_destruct itself sends a message to an object that is no longer valid and faults
at 0x0. Both are the same shape: an ivar of the encoder is released without the encoder holding a reference
to it — either stored unretained, or released one time too many.

It is not a race with the command buffer or with a draw. The stack is the teardown path, and in A it happens
while Espresso is still launching a convolution kernel — so whatever the encoder keeps (its bindings dictionary
is the one in A) is being torn down while the encode is in flight.

The reports
report when fault queue top frame
mediaanalysisd-2026-10-09-032907.ips 10-09 03:29 @0x0 com.apple.espresso.mainqueue objc_msgSend
mediaanalysisd-2026-10-09-045722.ips 10-09 04:57 @0x20 comm_safety_handler objc_release
mediaanalysisd-2026-10-09-105553.ips 10-09 10:55 @0x20 comm_safety_handler objc_release
mediaanalysisd-2026-10-10-143906.ips 10-10 14:39 @0x0 com.apple.espresso.mainqueue objc_msgSend
mediaanalysisd-2026-10-10-145603.ips 10-10 14:56 @0x20 comm_safety_handler objc_release
mediaanalysisd-2026-10-10-152958.ips 10-10 15:29 @0x20 comm_safety_handler objc_release
mediaanalysisd-2026-10-11-041422.ips 10-11 04:14 @0x20 comm_safety_handler objc_release

The bug is present in every driver version I have run (1.1.0 through 1.10.0) — the imageOffset of the
.cxx_destruct frame moves with the binary, the crash does not go away.

A second abort on the same path (1 report)

mediaanalysisd-2026-10-09-031540.ips, EXC_CRASH / SIGABRT, queue com.apple.espresso.mainqueue — an
assert() in NVK reached from an autorelease-pool pop:

 3  libsystem_c.dylib      __assert_rtn
 4  libvulkan_nouveau      nvk_FreeMemory.cold.2
 5  libvulkan_nouveau      nvk_FreeMemory
 6  NVMTLDriver            nvmtl_vk_buffer_destroy
 7  NVMTLDriver            -[NVMTLBuffer dealloc]
 8  CoreFoundation         -[__NSArrayI_Transfer dealloc]
 9  libobjc.A.dylib        AutoreleasePoolPage::releaseUntil(objc_object**)
10  libobjc.A.dylib        objc_autoreleasePoolPop
11  Espresso               espresso_plan_execute_sync
12  Vision                 -[VNShotflowNetwork runNetwork:inputIsBGR:]

It may well be unrelated to the encoder one — it is an NVK bookkeeping assert, not an over-release. I am putting
it here because it is the same shape in the same place (an NVMTL object destroyed at the wrong moment inside
Espresso), and because one report is not enough for its own issue. Say if you would rather have it separate and
I will split it out.

What would help
  • The crash is in our dealloc path, so the ivar .cxx_destruct releases is the thing to look at: whether
    anything the encoder stores is stored without a retain, or released somewhere else as well.
  • If there is a switch that keeps an encoder alive until its command buffer completes, or that logs when an
    encoder is deallocated while its command buffer is still open, I will turn it on and reproduce. The face
    detector path in mediaanalysisd hits this every few hours on its own, so it does not need to be forced.
Note

mediaanalysisd on this machine has six unrelated crash families; #50 is one of them and this is another. The
breakdown is in my comment on #50. I am watching for new reports and classifying them, so anything that shows up
here after a fix can be told apart from the rest.

中文版（Chinese version）
发生了什么

mediaanalysisd 以 EXC_BAD_ACCESS / SIGSEGV 死在 -[NVMTLComputeCommandEncoder .cxx_destruct] 里。
10-09 03:29 至 10-11 04:14 之间共 7 条报告，全部由 Espresso/MPS 的神经网络工作触发 —— Vision 的人脸检测
（VNShotflowNetwork）与 Espresso 的卷积 kernel。

这与 #50 是不同的崩溃。#50 是 NVK 里由绘制触发的 assert()；这一条是我们自己的 dealloc 路径上的
非法内存访问，不涉及任何 assert。

两种形态，同一个帧

形态 A —— 5 条，线程队列 comm_safety_handler，故障地址 0x20（栈见上）。

形态 B —— 2 条，线程队列 com.apple.espresso.mainqueue，故障地址 0x0（栈见上）。

两者合起来说明什么

A 中 .cxx_destruct 释放了一个字典 ivar，cow_cleanup 遍历该字典时释放其中一个条目，在 +0x20 处崩溃。
B 中 .cxx_destruct 自己向一个已失效的对象发消息，在 0x0 处崩溃。两者形态相同：encoder 的某个 ivar
在释放时 encoder 并不持有它的引用 —— 要么存的时候没 retain，要么多释放了一次。

这不是与 command buffer 或绘制的竞争。栈本身就是销毁路径，而 A 里它发生在 Espresso 仍在启动卷积 kernel
的过程中 —— 也就是说 encoder 持有的东西（A 里是它的 bindings 字典）在 encode 还在进行时就被拆掉了。

报告清单

见上方表格（7 条，含故障地址与线程队列）。

该 bug 在我跑过的每一个驱动版本上都存在（1.1.0 到 1.10.0）—— .cxx_destruct 帧的 imageOffset 随二进制
变化，崩溃本身不消失。

同一路径上的第二个 abort（1 条）

mediaanalysisd-2026-10-09-031540.ips，EXC_CRASH / SIGABRT，队列 com.apple.espresso.mainqueue ——
一个从 autorelease pool pop 到达的 NVK assert()（nvk_FreeMemory → nvmtl_vk_buffer_destroy →
-[NVMTLBuffer dealloc]）。

它很可能与 encoder 那条无关（那是 NVK 的记账断言，不是过度释放）。我把它放在这里，是因为形态与位置相同
（NVMTL 对象在 Espresso 内被在错误的时机销毁），而且只有一条报告不足以单独开 issue。如果你希望分开，我就
拆出去。

什么会有帮助
  • 崩溃在我们自己的 dealloc 路径上，所以 .cxx_destruct 释放的那个 ivar 就是要看的东西：encoder 存进去的
    东西里，有没有哪个是没 retain 就存的，或者在别处也被释放了一次。
  • 如果有开关能让 encoder 活到它的 command buffer 完成，或者在「encoder 在其 command buffer 仍打开时被
    dealloc」时打日志，我会打开它去复现。mediaanalysisd 里的人脸检测路径每隔几小时自己就会撞上，不需要强制
    触发。
备注

本机的 mediaanalysisd 有 6 个互不相关的崩溃族，#50 是其中之一，本条是另一个。分族明细在我给 #50 的评论
里。我在盯新报告并逐条分类，所以修复之后出现的东西能和其余几族区分开。

Dominant language
Rust
Stars
2.5k
Forks
233
Avg merge
1h 37m
Merged PRs (30d)
1

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from nullmoth/nvidia-macos-driver

All issues in nullmoth/nvidia-macos-driver

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.