Skip to content

Crash on message deletion: dust animation texture width (framebuffer × 3) exceeds Metal 16384 px limit on wide displays #1443

Description

@designabramov-cmd

Steps to reproduce

  1. Use a display whose framebuffer width is 5461 px or wider. In my case: an ultrawide 3440×1440 running a custom HiDPI scale via BetterDisplay, giving a 5504×2304 framebuffer.
  2. Open any chat, including Saved Messages.
  3. Delete any message.
  4. The app aborts immediately.

Also reproduces when a bot deletes a message — no user interaction with the message required. This rules out the context menu and points at the deletion animation itself.

Actual behaviour

100% reproducible crash, EXC_CRASH (SIGABRT). Assertion from stderr:

-[MTLTextureDescriptorInternal validateWithDevice:]:1421: failed assertion `Texture Descriptor Validation
MTLTextureDescriptor has width (16512) greater than the maximum allowed size of 16384.
'

Root cause

16512 = 5504 × 3, where 5504 is exactly my main display's framebuffer width. The delete (dust/disintegration) animation appears to allocate a texture atlas three times the width of the snapshot, and the result is not clamped against MTLDevice.maxTextureWidth (16384 on Apple Silicon).

This gives a hard threshold: any framebuffer wider than 5461 px (16384 / 3) crashes on every message deletion. Below it, the app works normally.

Confirmed by changing display scale only, with no other changes: at 80% scale (framebuffer 5504 px) it crashes every time; at 75% (~5160 px → 15480) it never crashes. Nothing else was modified.

This is likely why the bug is rare — standard Apple scaling options on common panels stay under the limit. It needs an unusually wide framebuffer, which typically means an ultrawide plus a custom scale.

Suggested fix

Clamp the texture dimensions to device.maxTextureWidth / maxTextureHeight before creating the descriptor, and fall back to skipping the animation if the snapshot cannot fit. Metal aborts the process on an invalid descriptor rather than returning an error, so an unchecked size is always fatal.

Environment

  • Telegram for macOS 12.9 (282526), Mac App Store — crashes
  • Telegram for macOS 12.9.1 (282650), direct build — crashes identically
  • macOS 27.0 (26A5388g)
  • Mac mini M2 (Mac14,3), 16 GB
  • Displays: 5504×2304 main (ultrawide, custom scale via BetterDisplay) + 1800×3200 secondary
  • Incident IDs: CFA5D03A-A642-432C-9472-C3A2EEF70AD4, 68B5F2B8-6E18-4336-9B27-D612822C58DB

Crash log

Thread 0 backtrace
0   libsystem_kernel.dylib   __pthread_kill + 8
1   libsystem_pthread.dylib  pthread_kill + 296
2   libsystem_c.dylib        abort + 148
3   libsystem_c.dylib        __assert_rtn + 284
4   Metal                    MTLReportFailure.cold.1 + 48
5   Metal                    MTLReportFailure + 840
6   Metal                    _MTLMessageContextEndNewNSErrorOrAbort(...) + 992
7   Metal                    -[MTLTextureDescriptorInternal validateWithDevice:] + 2244
8   AGXMetalG14G             -[AGXTexture initWithDevice:desc:iosurface:plane:slice:] + 140
9   Telegram                 0x104948878 0x102e88000 + 28051576
10  Telegram                 0x10494b310 0x102e88000 + 28062480
11  Telegram                 0x104949a10 0x102e88000 + 28056080
12  Telegram                 0x10494f954 0x102e88000 + 28080468
13  Telegram                 0x104948438 0x102e88000 + 28050488
14  QuartzCore               CA::Layer::display_if_needed(CA::Transaction*) + 788
15  QuartzCore               CA::Context::commit_transaction(...) + 684
16  QuartzCore               CA::Transaction::commit() + 652

Related

Same assertion and same stack, reported in April 2025 and closed without a fix: telegramdesktop/tdesktop#29154

I can test a fix on my configuration if that helps.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions