Telegram fails after 2026-06-26 Stable update

chandre · 27 June 2026 06:13

Hey. After Manjaro update (haven’t seen such fails before) start to observe random crashes of the Telegram (6.9.3).
Terminal outpute:

QEGLPlatformContext: Failed to create context: 3009
QRhiGles2: Failed to create temporary context
QEGLPlatformContext: Failed to create context: 3009
QRhiGles2: Failed to create context
error: empty dic file 
Hash Manager Error : 2
qt.gui.imageio.jpeg: Corrupt JPEG data: premature end of data segment
qt.gui.imageio.jpeg: Corrupt JPEG data: premature end of data segment
[h264 @ 0x55f8471a68c0] Increasing reorder buffer to 2
[libvpx-vp9 @ 0x55f83efeac00] v1.16.0
[libvpx-vp9 @ 0x55f84be173c0] v1.16.0
[libvpx-vp9 @ 0x55f84be173c0] v1.16.0
[h264 @ 0x55f848a51480] Increasing reorder buffer to 2
[h264 @ 0x55f84a5d8700] Increasing reorder buffer to 2
[h264 @ 0x55f84fced100] Increasing reorder buffer to 2
[h264 @ 0x55f8493bdb40] Increasing reorder buffer to 2
[h264 @ 0x55f851094a80] Increasing reorder buffer to 2
[h264 @ 0x55f84a82d200] Increasing reorder buffer to 2
[h264 @ 0x55f848ae5780] Increasing reorder buffer to 2
/usr/include/c++/16.1.1/semaphore:74: void std::counting_semaphore<__least_max_value>::release(std::ptrdiff_t) [with long int __least_max_value = 1; std::ptrdiff_t = long int]: Assertion '__update >= 0 && __update <= max() - __old' failed.
zsh: abort (core dumped)  Telegram

Could be that I’ve missed some additional info about the error, so please direct me where to look

linux-aarhus · 27 June 2026 06:19

Impossible to say but as telegram is built on top of electron - one could speculate if you are in some kind of partial update state.

telegram-desktop v6.9.3-7 is currently only available in unstable branch.

So if you are using stable branch I would think it is a custom package?

Given that I am using unstable branch - I tested the package and it runs fine when I open it using Telegram on the commandline.

chandre · 27 June 2026 06:24

Just installed from the extra repo:

❯ pamac info telegram-desktop | grep -Ei 'Name|Version|Repository|Install Date'

Name                  : telegram-desktop
Version               : 6.9.3-2
Repository            : extra
Install Date          : fr, 26-jun-2026 22:02:22 +0300

The crash happens randomly when going through several posts with videos

linux-aarhus · 27 June 2026 06:29

Impossible to say ~~but as telegram is built on top of electron~~ - one could speculate if you are in some kind of partial update state.

telegram-desktop v6.9.3-7 is currently available in unstable branch.

~~So if you are using stable branch I would think it is a custom package?~~

Given that I am using unstable branch - I tested the package and it runs fine when I open it using Telegram on the commandline.

linux-aarhus · 27 June 2026 06:32

I searched just telegram - that did not give me all info - sorry about that - you are correct telegram-desktop is in all branches - the version I used is the repackage of v6.9.3-7 pkgrel 7.

 $ mbn info telegram-desktop -q
Branch         : archlinux
Name           : telegram-desktop
Version        : 6.9.3-7
Repository     : extra
Build Date     : Wed 24 Jun 2026 11:51:54 
Packager       : Sven-Hendrik Haase <svenstaro@archlinux.org>
Branch         : unstable
Name           : telegram-desktop
Version        : 6.9.3-7
Repository     : extra
Build Date     : Wed 24 Jun 2026 11:51:54 
Packager       : Sven-Hendrik Haase <svenstaro@archlinux.org>
Branch         : testing
Name           : telegram-desktop
Version        : 6.9.3-2
Repository     : extra
Build Date     : Sat 13 Jun 2026 18:53:24 
Packager       : Felix Yan <felixonmars@archlinux.org>
Branch         : stable
Name           : telegram-desktop
Version        : 6.9.3-2
Repository     : extra
Build Date     : Sat 13 Jun 2026 18:53:24 
Packager       : Felix Yan <felixonmars@archlinux.org>

If you really need telegram - the only suggestion I can make is to switch branch.

sudo pacman -Syu testing && sudo pacman -Syyu

chandre · 27 June 2026 06:41

Thanks for suggestion. Seems like just an issue of the current version on the stable branch. So I’ll just wait for it’s update and just spend less time on telegram

Ben · 27 June 2026 06:53

pamac build forkgram

Hard to tell the difference - but it doesn’t stop working at the drop of a hat

nikgnomic · 27 June 2026 07:16

Telegram-desktop stopped working after update - #3 by wils0n

Telegram was crashing due to a corrupted Fontconfig cache, which caused Qt font rendering to segfault. Rebuilding the font cache fixed the issue.
rm -rf ~/.cache/fontconfig
sudo rm -rf /var/cache/fontconfig/*
fc-cache -rv

Lolix · 27 June 2026 10:08

Incorrect, it is a Qt6 program

Teo · 27 June 2026 11:41

The flatpak is always an option

nikgnomic · 27 June 2026 12:15

chandre · 27 June 2026 12:38

Thanks. Let’s see will it help

Update: so far no crashes

Update_2: Was to fast with conclusions, crashed again

Yochanan · 27 June 2026 21:09

A post generated by AI has been deleted.

chandre · 28 June 2026 12:07

Found bug report related to the issue on the telegram github with comprehensive root cause analysis in case someone is interested

github.com/telegramdesktop/tdesktop

6.9.x: SIGABRT on closing/finishing streamed media — over-release of crl::semaphore in Media::Streaming::File::Context::interrupt (symbolized; cf #30833)

opened 11:28PM - 15 Jun 26 UTC

closed 04:49PM - 24 Jun 26 UTC

enomado

Follow-up to the closed #30833 (dismissed as "3rd party issue"). That report onl…y had an unsymbolized stack, so it was attributed to Arch's libstdc++. I symbolized the coredump and the abort is a **real semaphore over-release inside tdesktop's own streaming code** — the libstdc++ assertion is merely catching it. Filing a fresh, symbolized report since the other one is closed. ### Steps to reproduce 1. On a build using a hardened libstdc++ (Arch's `_GLIBCXX_ASSERTIONS`), open a streamed video and close the media viewer, **or** let a voice/audio message finish playing. 2. Telegram aborts (`SIGABRT`) — reproducible ~100% of the time on closing a video for several users in #30833. ``` /usr/include/c++/16.1.1/semaphore:74: void std::counting_semaphore<__least_max_value>::release(std::ptrdiff_t) [with long int __least_max_value = 1]: Assertion '__update >= 0 && __update <= max() - __old' failed. ``` ### Symbolized backtrace Symbolized against the exact Arch `6.9.3-2` binary (build-id `7914059cd4e15f803231c242b4ebeffeeae5b980`) via `debuginfod.archlinux.org`: ``` #3 abort #4 std::__glibcxx_assert_fail ("…/semaphore", line 74, "std::counting_semaphore<1>::release(std::ptrdiff_t)", "__update >= 0 && __update <= max() - __old") #5 std::counting_semaphore<1l>::release (__update=1) semaphore:74 #6 crl::semaphore::release lib_crl/crl/common/crl_common_semaphore.h:27 #7 Media::Streaming::File::Context::interrupt media/streaming/media_streaming_file.cpp:419 #8 Media::Streaming::File::stop (stillActive=false) media/streaming/media_streaming_file.cpp:483 #9 Media::Streaming::Player::stop (stillActive=false) media/streaming/media_streaming_player.cpp:794 #10 Media::Streaming::Player::stop media/streaming/media_streaming_player.cpp:628 #11 Media::Streaming::Player::~Player media/streaming/media_streaming_player.cpp:1027 #12 std::_Sp_counted_base::_M_release_last_use shared_ptr_base.h #14 Media::View::OverlayWidget::Streamed::~Streamed media/view/media_view_overlay_widget.cpp:438 #19 Media::View::OverlayWidget::clearStreaming(bool) media/view/media_view_overlay_widget.cpp:1388 #20 Media::View::OverlayWidget::applyVideoQuality media/view/media_view_overlay_widget.cpp:5494 (reached from the quality-change rpl handler installed in OverlayWidget::initStreaming) ``` ### Root cause `Media::Streaming::File::Context::interrupt()` (`media_streaming_file.cpp:419`) calls `crl::semaphore::release()` → `std::counting_semaphore<1>::release(1)`. The binary semaphore is already at its max value (1), so the precondition `__update <= max() - __old` (`1 <= 1 - 1`) is violated → abort. I.e. a **double / redundant `release()`** on the streaming wakeup semaphore during media teardown. This dump reaches the teardown via `applyVideoQuality → clearStreaming`, but the same `~Player → Player::stop → File::stop → Context::interrupt → semaphore.release()` path runs whenever a streamed item is closed or finishes — matching the reports of aborting right when an audio message finishes or a video is closed. ### Why this is a tdesktop bug, not a distro/libstdc++ bug `_GLIBCXX_ASSERTIONS` does not introduce anything; it only makes the precondition violation fatal. On a libstdc++ built **without** assertions (e.g. the official static binary, which links the older el8 `15.2.1` libstdc++) the same `release()` is a **silent counter overflow / UB**, not a benign no-op. So the over-release is latent on every platform — the static build just hides it. That is why "use the static build" makes it merely *appear* fixed. Suggested fix: make `Context::interrupt()` idempotent (skip `release()` when the wakeup is already signaled), or use a wakeup primitive without an upper-bound precondition. ### Expected behaviour Closing / finishing streamed media does not abort. ### Actual behaviour `SIGABRT` from `std::counting_semaphore<1>::release` precondition violation. ### Operating system Arch / EndeavourOS, x86_64, Wayland and X11 both affected. ### Version of Telegram Desktop 6.9.x (6.9.2-1 and 6.9.3-2). 6.8.2 and earlier are unaffected. ### Installation source Distribution package (Arch `extra`, hardened libstdc++ build). I can provide the full 70-thread backtrace or test a patch.