Steps to reproduce
- 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.
- Open any chat, including Saved Messages.
- Delete any message.
- 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.
Steps to reproduce
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: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/maxTextureHeightbefore 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
CFA5D03A-A642-432C-9472-C3A2EEF70AD4,68B5F2B8-6E18-4336-9B27-D612822C58DBCrash log
Thread 0 backtrace
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.