telegramdesktop
4.14.15 crashes on Ubuntu 22.04 when opening a video.
Steps to reproduce
- Open Telegram.
- Click on a video.
Expected behaviour
The video player should open
Actual behaviour
Application crashes
Operating system
Ubuntu 22.04, CPU AMD A8-7600 Radeon R7
Version of Telegram Desktop
telegram-desktop 4.14.15 Rev=5557
Installation source
Snap
Crash ID
No response
Logs
dmesg:
[224175.957980] telegram-deskto[99171]: segfault at 40 ip 00007f2b8d955f9d sp 00007ffe93084f80 error 4 in radeonsi_dri.so[7f2b8d230000+136a000] likely on CPU 0 (core 0, socket 0)
[224175.958031] Code: 30 45 85 ed 0f 84 e2 00 00 00 45 31 ed 49 89 e4 eb 33 0f 1f 00 49 03 5e 38 48 8b 33 48 85 f6 74 0c f0 83 2e 01 75 06 48 89 ef <ff> 55 40 48 c7 03 00 00 00 00 41 8b 56 30 41 83 c5 01 41 39 d5 0f
Open Telegram.
Click on a video.
Did this, the result is
The video player should open
The report seem to be invalid or lacks something important in steps to reproduce
I'm having the same problem. When you click on a video or image in a message, Telegram closes and disappears from memory. I have Kubuntu 22.04 LTS and Telegram 4.14.15. On the same machine, but running Win11, such problems are not observed.
Sadly no developer is able to reproduce the issue what means work could not be started and the issue will be closed by a bot automatically unless someone would fix the steps to reproduce and notify about that.
that's all I can show:
[ 3814.926375] audit: type=1400 audit(1707829950.933:165): apparmor="DENIED" operation="capable" class="cap" profile="/snap/snapd/20671/usr/lib/snapd/snap-confine" pid=10758 comm="snap-confine" capability=12 capname="net_admin" [ 3814.926388] audit: type=1400 audit(1707829950.933:166): apparmor="DENIED" operation="capable" class="cap" profile="/snap/snapd/20671/usr/lib/snapd/snap-confine" pid=10758 comm="snap-confine" capability=38 capname="perfmon" [ 3815.169510] audit: type=1400 audit(1707829951.173:167): apparmor="DENIED" operation="open" class="file" profile="snap.telegram-desktop.telegram-desktop" name="/etc/openal/alsoft.conf" pid=10758 comm="telegram-deskto" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0 [ 3815.171315] audit: type=1107 audit(1707829951.177:168): pid=632 uid=102 auid=4294967295 ses=4294967295 subj=unconfined msg='apparmor="DENIED" operation="dbus_method_call" bus="system" path="/org/freedesktop/RealtimeKit1" interface="org.freedesktop.DBus.Properties" member="Get" mask="send" name="org.freedesktop.RealtimeKit1" pid=10758 label="snap.telegram-desktop.telegram-desktop" peer_pid=918 peer_label="unconfined" exe="/usr/bin/dbus-daemon" sauid=102 hostname=? addr=? terminal=?' [ 3815.172455] audit: type=1107 audit(1707829951.177:169): pid=632 uid=102 auid=4294967295 ses=4294967295 subj=unconfined msg='apparmor="DENIED" operation="dbus_method_call" bus="system" path="/org/freedesktop/RealtimeKit1" interface="org.freedesktop.DBus.Properties" member="Get" mask="send" name="org.freedesktop.RealtimeKit1" pid=10758 label="snap.telegram-desktop.telegram-desktop" peer_pid=918 peer_label="unconfined" exe="/usr/bin/dbus-daemon" sauid=102 hostname=? addr=? terminal=?' [ 3815.172526] audit: type=1107 audit(1707829951.177:170): pid=632 uid=102 auid=4294967295 ses=4294967295 subj=unconfined msg='apparmor="DENIED" operation="dbus_method_call" bus="system" path="/org/freedesktop/RealtimeKit1" interface="org.freedesktop.RealtimeKit1" member="MakeThreadRealtime" mask="send" name="org.freedesktop.RealtimeKit1" pid=10758 label="snap.telegram-desktop.telegram-desktop" peer_pid=918 peer_label="unconfined" exe="/usr/bin/dbus-daemon" sauid=102 hostname=? addr=? terminal=?' [ 3815.444437] audit: type=1107 audit(1707829951.449:171): pid=632 uid=102 auid=4294967295 ses=4294967295 subj=unconfined msg='apparmor="DENIED" operation="dbus_method_call" bus="system" path="/org/freedesktop/NetworkManager" interface="org.freedesktop.DBus.Properties" member="GetAll" mask="send" name="org.freedesktop.NetworkManager" pid=10758 label="snap.telegram-desktop.telegram-desktop" peer_pid=634 peer_label="unconfined" exe="/usr/bin/dbus-daemon" sauid=102 hostname=? addr=? terminal=?' [ 3815.516444] audit: type=1400 audit(1707829951.521:172): apparmor="DENIED" operation="ptrace" class="ptrace" profile="snap.telegram-desktop.telegram-desktop" pid=10758 comm="telegram-deskto" requested_mask="read" denied_mask="read" peer="unconfined" [ 3815.612289] audit: type=1326 audit(1707829951.617:173): auid=1000 uid=1000 gid=1000 ses=3 subj=snap.telegram-desktop.telegram-desktop pid=10758 comm="telegram-deskto" exe="/snap/telegram-desktop/5557/usr/bin/telegram-desktop" sig=0 arch=c000003e syscall=203 compat=0 ip=0x7fa5aa6f8531 code=0x50000 [ 3815.612295] audit: type=1326 audit(1707829951.617:174): auid=1000 uid=1000 gid=1000 ses=3 subj=snap.telegram-desktop.telegram-desktop pid=10758 comm="telegram-deskto" exe="/snap/telegram-desktop/5557/usr/bin/telegram-desktop" sig=0 arch=c000003e syscall=141 compat=0 ip=0x7fa5aa77778b code=0x50000 [ 3912.255921] kauditd_printk_skb: 7 callbacks suppressed [ 3912.255923] audit: type=1326 audit(1707830048.260:182): auid=1000 uid=1000 gid=1000 ses=3 subj=snap.telegram-desktop.telegram-desktop pid=10758 comm="telegram-deskto" exe="/snap/telegram-desktop/5557/usr/bin/telegram-desktop" sig=0 arch=c000003e syscall=141 compat=0 ip=0x7fa5aa77778b code=0x50000 [ 3912.256988] telegram-deskto[10758]: segfault at 40 ip 00007f788b5cdf9d sp 00007ffc3356f3e0 error 4 in radeonsi_dri.so[7f788aea8000+136a000] likely on CPU 7 (core 3, socket 0) [ 3912.256997] Code: 30 45 85 ed 0f 84 e2 00 00 00 45 31 ed 49 89 e4 eb 33 0f 1f 00 49 03 5e 38 48 8b 33 48 85 f6 74 0c f0 83 2e 01 75 06 48 89 ef <ff> 55 40 48 c7 03 00 00 00 00 41 8b 56 30 41 83 c5 01 41 39 d5 0f
Sadly this is of no help. I recommend to install a fresh copy of the OS to a VM to get what developers have. Once you will be able to reproduce there, you will likely know what is missing.
Telegram not only crashes when opening a video, also when opening a image. It crashes even when it receives a call. One ring and boom ... It crashes all the time for me. it became unfortunately largely useless with the last version, 4.14.15, ubuntu snap.
[ 5950.669752] telegram-deskto[12103]: segfault at 40 ip 00007f7fcb938f9d sp 00007ffdf3b20840 error 4 in radeonsi_dri.so[7f7fcb213000+136a000] likely on CPU 3 (core 3, socket 0)
[ 5950.669764] Code: 30 45 85 ed 0f 84 e2 00 00 00 45 31 ed 49 89 e4 eb 33 0f 1f 00 49 03 5e 38 48 8b 33 48 85 f6 74 0c f0 83 2e 01 75 06 48 89 ef <ff> 55 40 48 c7 03 00 00 00 00 41 8b 56 30 41 83 c5 01 41 39 d5 0f
@ilya-fedin what better information do you need, than memory addresses, that show where the error occurs? And how can i provide that additional information to you? How many places would there be in the code, that would deliver faulty data to the gfx driver in the context of displaying a video or image? Your developers cannot reproduce, maybe because they use a nvidia? or other gfx? Would you have a developer, that uses a gfx with radeonsi_dri? How can i help you to fix this?
what better information do you need, than memory addresses, that show where the error occurs?
Well, the memory address says nothing to me... Do you mean you can gather something from memory address? I need either a way to reproduce or a high quality backtrace but the latter is not possible with snap sadly.
How many places would there be in the code, that would deliver faulty data to the gfx driver in the context of displaying a video or image?
Are you sure it's the case? Maybe it's a bug in the driver? Buggy drivers are the most frequent cause of crashes.
Your developers cannot reproduce, maybe because they use a nvidia? or other gfx?
Well, we do testing only in VMs. @john-preston uses Parallel as far as I'm aware (but I'm not sure whether he tests snaps at all, I guess he tests only the static binary) while I use libvirt with virtio but without 3D acceleration as the VMs are unusable with it (so it's llvmpipe practically). Sadly my host distro doesn't support snaps.
If this is hardware-dependent, this most likely means it's a bug in the driver and there's nothing could be done about that. The best course of action is reporting to mesa but I'm not sure how you folks will do it given that mesa developers are likely to require high quality backtraces just as well.
I see, so you have no way to reproduce that. Could it possibly be a good idea, for a application, that relies on gfx, to have a pool of real hardware to test it with? Just saying ...
Could it possibly be a good idea, for a application, that relies on gfx, to have a pool of real hardware to test it with? Just saying ...
Well, there's some group of testers of Windows and macOS users but there's nothing anything like that for Linux, perhaps due to its too low market share.
Looks like mesa 24 was released a week ago, that's perhaps the cause of such a big regression
Yeah, if it was up to me to decide, I'd drop snap package entirely as there are things that prevent solving problems with it (like the lack of debugging possibilities). But it's not up to me. I can only recommend to switch from snap to the static binary which is the main and the mostly tested distribution method.
@ilya-fedin I see, i think i understand. I apologize if i appeared unfriendly, that was not my intention. So best greetings to your decision maker, shipping a non-functional product is rather useless. If i cannot use the snap version, because it crashes on me, it doesnt matter, if you invested the time and money to provide a snap version in the first place. And it doesnt get better, if nobody bothers to fix things either, because: not enough users. This is just nonsensical.
Anyway, as a exemplaire open source user, i cloned the repo, installed the requirements and started a build ... just maybe so i can reproduce, catch the error at said address and maybe provide a workaround or fix ... but, the build is running for over 10000 seconds now, so i think i better leave that to the tdesktop team ... unless maybe there is a faster build option?
i cloned the repo, installed the requirements and started a build ...
I'm not sure that will help you to debug? If you're building a snap (that is, by running snapcraft in the root of the repo) without any changes to snapcraft.yaml, you will just get the same package as in the store, with the same lack of debug symbols. If you're following the Docker instruction, you will get a static binary that won't have this problem (assuming so given that only snap users seem to be affected).
If i cannot use the snap version, because it crashes on me, it doesnt matter, if you invested the time and money to provide a snap version in the first place. And it doesnt get better, if nobody bothers to fix things either, because: not enough users. This is just nonsensical.
I think there's a more free software-like logic: people have PRed snap support, it was merged because why not, it gets fixes when it's known how to fix and is just ignored (patches welcome) when not. If you like it, you use it, if you don't like it, you just peek another build.
To get something debuggable in the snap, one has to remove -s from LDFLAGS of the parts and --strip from meson-parameters, replace -DCMAKE_BUILD_TYPE=Release with -DCMAKE_BUILD_TYPE=RelWithDebInfo, --buildtype=release with --buildtype=debugoptimized, qt should get a -force-debug-info parameter in addition to -release and rnnoise should get -g instead of -s in CFLAGS.
This covers only parts built from source. To get debug symbols for dependencies gotten from repositories (which mesa is), one should also get debug symbols from the repositories staged in the snap package. If I'm not mistaken, in the past Debian distribution family has packaged debug symbols into packages ending with -dbg but I'm not sure how it's done now, I can't find any -dbg packages on the Ubuntu's package search web page (packages.ubuntu.com).
For doing some workaround like detecting the crash and automatically disabling OpenGL, debug symbols for tdesktop itself and Qt should be enough.
Thanks, I just wanted something to tinker with and go from there ... i will figure it out ... eventually ... maybe
Suddenly the build finished ... and i can confirm ... using the build ... that the crash does NOT happen. Nothing to fix, except for the snap thing maybe, ill try that next ...
To clarify:
- I made sure OpenGL is enabled
- its the Docker build
... it fails, because it must be from the 80's or something, complaining about internet connectivity. Ethernet no good? Anyway, here is the message:
craft-providers error: A network related operation failed in a context of no network access.
Verify that the environment has internet connectivity; see https://craft-providers.readthedocs.io/ for further reference.
I read the docs, but there is nothing about internet. I give up, unless maybe @ilya-fedin you have another tip for me?
I can further confirm, that the static build provided via link from the repos root also does NOT crash. So the fix is easy: Uninstall snap versions, install another version.
I read the docs, but there is nothing about internet. I give up, unless maybe @ilya-fedin you have another tip for me?
Do you have both snapcraft and lxd installed from snap?
I read the docs, but there is nothing about internet. I give up, unless maybe @ilya-fedin you have another tip for me?
Do you have both snapcraft and lxd installed from snap?
yes
Just remembered that docker could conflict with lxd due to its iptables changes one of which changes default FORWARD policy to DROP. iptables -P FORWARD ACCEPT should help but if not it may be a good idea to disable docker service or remove docker and reboot to clean iptables
... 3 weeks later ... the build finished. I can confirm telegram-desktop_4.14.15-3-g8b6a7a443_amd64.snap to be crashing.
I noticed, that the snap may pull in different versions of libraries than the other builds. At least maybe thats something to look at or verify, as it may be a possible cause for this issue. Thanks @ilya-fedin for the guidance. Ill give up now, problem is fixed for my by using the other builds. Well, and builds just take way to long for me to continue tinkering.
I noticed, that the snap may pull in different versions of libraries than the other builds.
I'm not sure what you mean exactly but if I understand you right, that's expected as snap ecosystem provides almost everything with Ubuntu packages (and I hope it would be possible to replace some of currently self-built libraries with the packaged ones with core24)
If you look at snapcraft.yaml it demands libwhateversomethingfancy, but it doesnt say which version of it. That would explain, why builds behave differently, as it may pull in a different version of the libwhateversomethingfancy as the other builds
I'm not sure what you mean exactly but if I understand you right, that's expected
I see, i dont know snap, maybe.
It pulls whatever the version currently is in the repository, yeah, if they push a new version of a package to the repository, the next build of the snap package would use a different one. That's just how snapcraft works...