Closed bzzz77 closed 8 months ago
Provide a crash ID as instructed when you creating an issue
I can't get crash ID. so I download beta version, start it, it fetches an update and that's it - crashes on start again and again: `Feb 16 20:29:36 x390 kernel: audit: type=1130 audit(1708104576.198:2285): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=kernel msg='unit=systemd-coredump@48-300078-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Feb 16 20:29:36 x390 systemd-coredump[300079]: [🡕] Process 300058 (Telegram) of user 1000 dumped core.
Module libduktape.so.207 from rpm duktape-2.7.0-2.fc38.x86_64
Module pacrunner_duktape.so from rpm libproxy-0.4.18-6.fc38.x86_64
Module libproxy.so.1 from rpm libproxy-0.4.18-6.fc38.x86_64
Module libgiolibproxy.so from rpm glib-networking-2.76.1-1.fc38.x86_64
Module libdconfsettings.so from rpm dconf-0.40.0-8.fc38.x86_64
Module libgiognomeproxy.so from rpm glib-networking-2.76.1-1.fc38.x86_64
Module libgvfscommon.so from rpm gvfs-1.50.7-1.fc38.x86_64
Module libgvfsdbus.so from rpm gvfs-1.50.7-1.fc38.x86_64
Module libjson-glib-1.0.so.0 from rpm json-glib-1.6.6-4.fc38.x86_64
Module libatspi.so.0 from rpm at-spi2-core-2.48.4-1.fc38.x86_64
Module libtracker-sparql-3.0.so.0 from rpm tracker-3.5.3-2.fc38.x86_64
Module libcloudproviders.so.0 from rpm libcloudproviders-0.3.5-1.fc38.x86_64
Module libatk-bridge-2.0.so.0 from rpm at-spi2-core-2.48.4-1.fc38.x86_64
Module libatk-1.0.so.0 from rpm at-spi2-core-2.48.4-1.fc38.x86_64
Module libgtk-3.so.0 from rpm gtk3-3.24.41-1.fc38.x86_64
Module libdatrie.so.1 from rpm libdatrie-0.2.13-5.fc38.x86_64
Module libpangoft2-1.0.so.0 from rpm pango-1.50.14-1.fc38.x86_64
Module libthai.so.0 from rpm libthai-0.1.29-4.fc38.x86_64
Module libpixman-1.so.0 from rpm pixman-0.42.2-1.fc38.x86_64
Module libxcb-shm.so.0 from rpm libxcb-1.13.1-11.fc38.x86_64
Module libxcb-render.so.0 from rpm libxcb-1.13.1-11.fc38.x86_64
Module libXrender.so.1 from rpm libXrender-0.9.11-2.fc38.x86_64
Module libjpeg.so.62 from rpm libjpeg-turbo-2.1.4-2.fc38.x86_64
Module libXinerama.so.1 from rpm libXinerama-1.1.5-2.fc38.x86_64
Module libXrandr.so.2 from rpm libXrandr-1.5.2-10.fc38.x86_64
Module libXcomposite.so.1 from rpm libXcomposite-0.4.5-9.fc38.x86_64
Module libXfixes.so.3 from rpm libXfixes-6.0.0-5.fc38.x86_64
Module libXdamage.so.1 from rpm libXdamage-1.1.5-9.fc38.x86_64
Module libXcursor.so.1 from rpm libXcursor-1.2.1-3.fc38.x86_64
Module libXext.so.6 from rpm libXext-1.3.5-2.fc38.x86_64
Module libXi.so.6 from rpm libXi-1.8.1-1.fc38.x86_64
Module libwayland-egl.so.1 from rpm wayland-1.22.0-1.fc38.x86_64
Module libwayland-cursor.so.0 from rpm wayland-1.22.0-1.fc38.x86_64
Module libwayland-client.so.0 from rpm wayland-1.22.0-1.fc38.x86_64
Module libxkbcommon.so.0 from rpm libxkbcommon-1.5.0-2.fc38.x86_64
Module libpangocairo-1.0.so.0 from rpm pango-1.50.14-1.fc38.x86_64
Module libepoxy.so.0 from rpm libepoxy-1.5.10-3.fc38.x86_64
Module libcairo-gobject.so.2 from rpm cairo-1.17.8-4.fc38.x86_64
Module libfribidi.so.0 from rpm fribidi-1.0.12-3.fc38.x86_64
Module libpango-1.0.so.0 from rpm pango-1.50.14-1.fc38.x86_64
Module libcairo.so.2 from rpm cairo-1.17.8-4.fc38.x86_64
Module libgdk_pixbuf-2.0.so.0 from rpm gdk-pixbuf2-2.42.10-2.fc38.x86_64
Module libgdk-3.so.0 from rpm gtk3-3.24.41-1.fc38.x86_64
Module libX11-xcb.so.1 from rpm libX11-1.8.7-1.fc38.x86_64
Module liblz4.so.1 from rpm lz4-1.9.4-2.fc38.x86_64
Module libzstd.so.1 from rpm zstd-1.5.5-1.fc38.x86_64
Module libcap.so.2 from rpm libcap-2.48-8.fc38.x86_64
Module libsystemd.so.0 from rpm systemd-253.15-2.fc38.x86_64
Module libdbus-1.so.3 from rpm dbus-1.14.10-1.fc38.x86_64
Module libblkid.so.1 from rpm util-linux-2.38.1-4.fc38.x86_64
Module libXau.so.6 from rpm libXau-1.0.11-2.fc38.x86_64
Module libbrotlicommon.so.1 from rpm brotli-1.0.9-11.fc38.x86_64
Module libgraphite2.so.3 from rpm graphite2-1.3.14-11.fc38.x86_64
Module liblzma.so.5 from rpm xz-5.4.1-1.fc38.x86_64
Module libpcre2-8.so.0 from rpm pcre2-10.42-1.fc38.1.x86_64
Module libffi.so.8 from rpm libffi-3.4.4-2.fc38.x86_64
Module libselinux.so.1 from rpm libselinux-3.5-1.fc38.x86_64
Module libmount.so.1 from rpm util-linux-2.38.1-4.fc38.x86_64
Module libgmodule-2.0.so.0 from rpm glib2-2.76.6-1.fc38.x86_64
Module libxcb.so.1 from rpm libxcb-1.13.1-11.fc38.x86_64
Module libbrotlidec.so.1 from rpm brotli-1.0.9-11.fc38.x86_64
Module libharfbuzz.so.0 from rpm harfbuzz-7.1.0-1.fc38.x86_64
Module libz.so.1 from rpm zlib-1.2.13-3.fc38.x86_64
Module libpng16.so.16 from rpm libpng-1.6.37-14.fc38.x86_64
Module libbz2.so.1 from rpm bzip2-1.0.8-13.fc38.x86_64
Module libxml2.so.2 from rpm libxml2-2.10.4-1.fc38.x86_64
Module libglib-2.0.so.0 from rpm glib2-2.76.6-1.fc38.x86_64
Module libgobject-2.0.so.0 from rpm glib2-2.76.6-1.fc38.x86_64
Module libgio-2.0.so.0 from rpm glib2-2.76.6-1.fc38.x86_64
Module libX11.so.6 from rpm libX11-1.8.7-1.fc38.x86_64
Module libfreetype.so.6 from rpm freetype-2.13.0-2.fc38.x86_64
Module libfontconfig.so.1 from rpm fontconfig-2.14.2-1.fc38.x86_64
Stack trace of thread 300076:
#0 0x00007f3eaaaee884 __pthread_kill_implementation (libc.so.6 + 0x8e884)
#1 0x00007f3eaaa9dafe raise (libc.so.6 + 0x3dafe)
#2 0x00007f3eaaa8687f abort (libc.so.6 + 0x2687f)
#3 0x00007f119c3bd6fe _Unwind_SetGR.cold (libgcc_s.so.1 + 0x36fe)
#4 0x00007f119c3d7bd3 __gcc_personality_v0 (libgcc_s.so.1 + 0x1dbd3)
#5 0x000056334c4ecad5 n/a (/home/alexey/Downloads/tmp/Telegram/Telegram + 0x6e25ad5)
#6 0x0000000000000000 n/a (n/a + 0x0)
ELF object binary architecture: AMD x86-64
`
I used tsetup.4.14.11.beta.tar.xz
cant reproduce myself with fedora 39 and telegram desktop 4.14.16
Can you upload the last dump (sort by creation or modification date) from ~/.local/share/TelegramDesktop/tdata/dumps
?
I confirm, the problem is relevant to me as well. Error: Could not activate remote peer: unit failed. Fedora 38
Same here: Fedora 38, KDE Plasma (X11), Kernel 6.6.14... Telegram crashes at startup after automatic upgrade 4.14.15 -> 4.14.16 (from binary tarball)... never had any issues before. Even with "automatic update" turned off, Telegram auto-updates at startup and crashes again.
hope there is no private data inside..
No, those dumps are in Windows minidump format
Please provide a screenshot of your system proxy settings
Same on Fedora 37, under Xfce. I even pulled files from an older version on my other computer, but this just auto-updated and then crashed again. dump.zip
I don't have any proxy setup anywhere (method "None" in Network Manager).
Please provide a screenshot of your system proxy settings
FIXED it for me (Fedora 38): changing "Use system proxy settings" -> "Disable proxy"! now auto-updating to 4.14.16 without issues...
@gashloog, how do you change that when Telegram crashes when run?
@vsego
how do you change that when Telegram crashes when run?
I run version 4.14.15 from the binary tarball and before restarting again, change the proxy settings... it crashes only when I restart without setting the proxy settings as mentioned above...
After removing Telegram completely, run from 4.14.15 (binary tarball) -> change proxy settings to "Disable proxy" -> close/restart... then it auto-updates to 4.14.16 without issues... for me...
I bet setting GTK_USE_PORTAL=1
environment variable would make it run as well
Ok, that did it. To be clear:
export GTK_USE_PORTAL=1
and then run Telegram from the same console, as @ilya-fedin suggested.GTK_USE_PORTAL
(i.e., it can be run from a GUI menu).Thank you both.
There was a similar report recently, #27177 and setting SCUDO_OPTIONS=delete_size_mismatch=false
has helped there. I wonder whether it helps here?
There was a similar report recently, #27177 and setting
SCUDO_OPTIONS=delete_size_mismatch=false
has helped there. I wonder whether it helps here?
It does not.
Also, Telegram crashes the moment you change the proxy setting (back) to "Uses system proxy settings".
ok, so apparently it's different
@bzzz77 can you remove fedora 38 from the title? people seem to create duplicates due to that
@bzzz77 have you made a typo? Most of the commenters here say it has appeared in 4.14.16, not 4.14.15 and now people refuse to close their duplicates claiming they have problems with 4.14.16 only.
@ilya-fedin you're right. let me fix it.
Crash ID: 37f92807-ccc0-4a89-77c5edbf-31169a43
Crash ID: e5a5ae4d-3da7-4c1e-dc8bde9e-78da7265
@john-preston finally sent me a crash trace from some of the crash reports:
Crash reason: SIGABRT
Crash address: 0x3e80003afd5
Process uptime: not available
Thread 6 (crashed)
0 libc.so.6 + 0x8ce5c
rax = 0x0000000000000000 rdx = 0x0000000000000006
rcx = 0x00007f539dfcae5c rbx = 0x000000000003afe4
rsi = 0x000000000003afe4 rdi = 0x000000000003afd5
rbp = 0x00007f2689dfe6c0 rsp = 0x00007f2689df9540
r8 = 0x00007f2689df9698 r9 = 0x0000000000000000
r10 = 0x0000000000000008 r11 = 0x0000000000000246
r12 = 0x0000000000000006 r13 = 0x00007f268252b527
r14 = 0x00007f268252b4f6 r15 = 0x00007f2682541f58
rip = 0x00007f539dfcae5c
Found by: given as instruction pointer in context
1 libproxy.so.1 + 0x7527
rbp = 0x00007f2689dfe6c0 rsp = 0x00007f2689df9570
rip = 0x00007f268252b527
Found by: stack scanning
2 libproxy.so.1 + 0x74f6
rbp = 0x00007f2689dfe6c0 rsp = 0x00007f2689df9578
rip = 0x00007f268252b4f6
Found by: stack scanning
3 libc.so.6 + 0x3ca76
rbp = 0x00007f2689dfe6c0 rsp = 0x00007f2689df9580
rip = 0x00007f539df7aa76
Found by: stack scanning
4 libc.so.6 + 0x267fc
rbp = 0x00007f2689dfe6c0 rsp = 0x00007f2689df9590
rip = 0x00007f539df647fc
Found by: stack scanning
5 ld-linux-x86-64.so.2 + 0x2700c
rbp = 0x00007f2689dfe6c0 rsp = 0x00007f2689df95a0
rip = 0x00007f539e82000c
Found by: stack scanning
6 Telegram!get_cie_encoding + 0xd8
rbp = 0x00007f2689dfe6c0 rsp = 0x00007f2689df95e0
rip = 0x000055e33c317f78
Found by: stack scanning
7 Telegram!_Unwind_Find_FDE + 0x37f
rbx = 0x00007f268253efc4 rbp = 0x00007f268252b527
rsp = 0x00007f2689df9610 rip = 0x000055e33c31981f
Found by: call frame info
8 libproxy.so.1 + 0x7527
rsp = 0x00007f2689df9638 rip = 0x00007f268252b527
Found by: stack scanning
9 libproxy.so.1 + 0x755a
rsp = 0x00007f2689df9640 rip = 0x00007f268252b55a
Found by: stack scanning
10 libgcc_s.so.1 + 0x369e
rsp = 0x00007f2689df9650 rip = 0x00007f268e8e069e
Found by: stack scanning
11 libgcc_s.so.1 + 0x198fb
rsp = 0x00007f2689df9660 rip = 0x00007f268e8f68fb
Found by: stack scanning
12 libproxy.so.1 + 0x74f6
rsp = 0x00007f2689df96a8 rip = 0x00007f268252b4f6
Found by: stack scanning
13 libproxy.so.1 + 0x74f6
rsp = 0x00007f2689df96b0 rip = 0x00007f268252b4f6
Found by: stack scanning
14 Telegram!_Unwind_RaiseException_Phase2 + 0x65
rsp = 0x00007f2689df9710 rip = 0x000055e33c316ad5
Found by: stack scanning
15 Telegram!_Unwind_RaiseException + 0x310
rbx = 0x00007f2689df99d0 rbp = 0x00007f2689df9c80
rsp = 0x00007f2689df98e0 r12 = 0x00007f2689df9ac0
r13 = 0x00007f289da6f490 r14 = 0x000055e33fb37070
r15 = 0x00007f2689df98e0 rip = 0x000055e33c3172e0
Found by: call frame info
16 Telegram!__cxa_throw + 0x3a
rax = 0x00007f289da6f430 rdx = 0x000055e33c254eb0
rbx = 0x00007f289da6f490 rbp = 0x000055e33f1c56f0
rsp = 0x00007f2689df9c90 r12 = 0x000055e33c254eb0
r13 = 0x0000000000000006 r14 = 0x00007f2689df9d00
r15 = 0x0000000000000008 rip = 0x000055e33c24900a
Found by: call frame info
17 libproxy.so.1 + 0x7528
rbx = 0x00007f2689df9fb0 rbp = 0x0000000000000000
rsp = 0x00007f2689df9cb0 r12 = 0x00007f289da6f4b0
r13 = 0x0000000000000006 r14 = 0x00007f2689df9d00
r15 = 0x0000000000000008 rip = 0x00007f268252b528
Found by: call frame info
18 Telegram!operator delete(void*, unsigned long) [wrappers_cpp.cpp : 72 + 0x5]
rsp = 0x00007f2689df9d10 rip = 0x000055e336665732
Found by: stack scanning
19 libproxy.so.1 + 0xb52d
rsp = 0x00007f2689df9d30 rip = 0x00007f268252f52d
Found by: stack scanning
20 Telegram!__cxxabiv1::__si_class_type_info::__do_dyncast(long, __cxxabiv1::__class_type_info::__sub_kind, __cxxabiv1::__class_type_info const*, void const*, __cxxabiv1::__class_type_info const*, void const*, __cxxabiv1::__class_type_info::__dyncast_result&) const + 0x123
rsp = 0x00007f2689df9d70 rip = 0x000055e33c249603
Found by: stack scanning
21 0x1df62506bf867d00
rbx = 0x00007f439db46250 rbp = 0x00007f2682544800
rsp = 0x00007f2689df9dd0 r12 = 0x00007f2682544848
r13 = 0x0000000000000000 r14 = 0x0000000000000008
r15 = 0x0000000000000200 rip = 0x1df62506bf867d00
Found by: call frame info
22 libproxy.so.1 + 0x7e50
rsp = 0x00007f2689df9de8 rip = 0x00007f268252be50
Found by: stack scanning
23 libproxy.so.1 + 0x7e50
rsp = 0x00007f2689df9e10 rip = 0x00007f268252be50
Found by: stack scanning
24 libproxy.so.1 + 0x11467
rsp = 0x00007f2689df9e30 rip = 0x00007f2682535467
Found by: stack scanning
This sadly doesn't really help, the built-in crash reporting system bugs and provides meaningless traces as always :(
Can someone help by building a debug binary and getting a qualified trace?
Kubuntu 22.10
Having difficulty keeping Telegram 4.14.16 running (random closures)
Log was probably overwritten on latest restart, sorry. Here's the dump:
78700209-2940-4355-c5a08eb1-4e1ff558.zip
Now running with env GTK_USE_PORTAL=1 ... as a possible workaround.
@Daxx sadly dumps generated by tdesktop seem to be broken, they are of no help :(
Given that we can't reproduce this in our development environment to debug this and that no one is wiling to help with debugging on their machines (which requires building a debug binary), it was decided to disable support of reading system proxy settings on Linux. System Linux libraries seem to be too bugged.
@ilya-fedin I would help, but I do not know how to create such a file.
Which file? A debug build? it's instructed at https://github.com/telegramdesktop/tdesktop/blob/dev/docs/building-linux.md but may require up to 64 GB of RAM or swap. This takes multiple hours on middle-end computers and god knows how much time it would take on low-end pc due to excessive swapping. But this would help a lot.
@ilya-fedin I have 8 GB and the same amount of swap, but I can try
You can enlarge the amount of swap. The resulting binary is of 6 GB size so uploading it to internet is not really possible.
i have tried:
fedora 39 fedora 38 fedora 38 kde linux mint 21.3
cannot reproduce crash with system proxy enabled and telegram desktop 4.14.16
I managed to reproduce with a weird combo of environment variables: HTTP_PROXY= GIO_USE_PROXY_RESOLVER=libproxy ./Telegram
Can someone do env | grep PROXY
?
Can someone do
env | grep PROXY
?
That's empty for me. Not surprising because I don't use a proxy.
Been running without problems for several hours with GTK_USE_PORTAL=1
You mean no variables or there are variables with empty value? Can you provide the result of dpkg -l | grep libproxy
?
There's no output (so no variables with PROXY)
dpkg -l | grep libproxy
$ dpkg -l | grep libproxy
ii libproxy-tools 0.4.17-2 amd64 automatic proxy configuration management library (tools)
ii libproxy1v5:amd64 0.4.17-2 amd64 automatic proxy configuration management library (shared)
ii libproxy1v5:i386 0.4.17-2 i386 automatic proxy configuration management library (shared)
Thanks, it's quite weird though, it's the same for me but I can reproduce only with the mentioned variables
@ilya-fedin I have 8 GB and the same amount of swap, but I can try
I've been trying also; probably a better chance with 24 GB and 60 GB swap available but ./tdesktop/Telegram/build/prepare/linux.sh
failed after a few hours ...
ERROR: failed to solve: process "bash -c . /opt/rh/gcc-toolset-12/enable; .....
Ugh, Red Hat stuff -- doesn't exist on my system -- I have gcc12 installed but I'd rather not start debugging the debugging process when I don't know what it's trying to do ... especially as the initial problem seems to have gone away :)
It needs gcc 12 in container, not on your system. If you're using Red Hat family, the cause is likely that you have podman rather than real docker and the solution is likely to install the real docker from Docker's website
I installed Docker using the .deb
as instructed on their website ..... but I did install poetry and that did a load of work.
Have I overwritten the good Docker I had by using poetry, I wonder?
Not poetry, podman. poetry is just a python dependency manager.
At the moment the issue looks to me like https://github.com/libproxy/libproxy/issues/277 / https://github.com/libproxy/libproxy/issues/199.
Podman not installed here. I think I've got the real Docker
$ docker compose version
Docker Compose version v2.24.5-desktop.1
$ docker --version
Docker version 25.0.3, build 4debf41
Installing it from official website could still solve the problem as Ubuntu doesn't update packages once the distro is released so you don't get latest bugfixes.
or maybe you haven't provided the real error but the last line instead?
Steps to reproduce
Expected behaviour
should work as usual
Actual behaviour
[alexey@x390 ~]$ ~/Downloads/tmp/Telegram/Telegram Aborted (core dumped)
Operating system
fedora 38
Version of Telegram Desktop
4.14.16
Installation source
Static binary from official website
Crash ID
No response
Logs
No response