Tdesktop: Thread 342 "QNetworkAccessM" received signal SIGSEGV, Segmentation fault

[flash207111]

Steps to reproduce

1. run gdb /usr/bin/telegram-desktop 2>&1 | tee ~/backtrace.log
2. segfault
3. this issue

Expected behaviour

Tell us what should happen

Actual behaviour

Tell us what happens instead

Configuration

Operating system:
fedora 29
Version of Telegram Desktop:
telegram-desktop-1.4.0-1.fc29.x86_64
Used theme:
default
backtrace.log

Logs:

Insert log.txt here (if necessary)

[Aokromes]

you are trying to run fedora core's package no? not official one, if so it doesn't belongs here.

[xvitaly]

The package was probably build against Fedora 28 whichhas qt 5.10 and Fedora 29 has 5.11.

You are not right.

Telegram Desktop is crashing while downloading files if connection suddenly disappears (cable removed for example). This is not a build issue at all.

not official one, if so it doesn't belongs here

Official blob is completely unusable on any Linux distribution. Resolve it's bugs with fontconfig first (lots of bug reports in this issue tracker).

[Johnnynator]

You are not right.

Telegram Desktop is crashing while downloading files if connection suddenly disappears (cable removed for example). This is not a build issue at all.

Sry that I did only had a really short glance at the backtrace and missed that it segfaulted in different Thread and not the main one. Also the bug report is only a backtrace. You post has way more info of what triggered it.

Also if I'm not mistaken #5221 is the same issue.

[koderrr]

Also if I'm not mistaken #5221 is the same issue.

I had the same issue on Arch Linux with community/telegram-desktop 1.4.3, and when I installed the software from sources by doing sudo pakku -S telegram-desktop-dev it stopped segfaulting every goddamn 10 minutes.

Upd: nope, it just became much less frequent.

Thread 22 "QNetworkAccessM" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffb8ff9700 (LWP 23127)]
0x00007ffff5e62ca4 in ?? () from /usr/lib/libQt5Network.so.5
(gdb) bt
#0  0x00007ffff5e62ca4 in  () at /usr/lib/libQt5Network.so.5
#1  0x00007ffff5e6159b in  () at /usr/lib/libQt5Network.so.5
#2  0x00007ffff4edc352 in QObject::event(QEvent*) () at /usr/lib/libQt5Core.so.5
#3  0x00007ffff58bae14 in QApplicationPrivate::notify_helper(QObject*, QEvent*) ()
    at /usr/lib/libQt5Widgets.so.5
#4  0x00007ffff58c26e1 in QApplication::notify(QObject*, QEvent*) () at /usr/lib/libQt5Widgets.so.5
#5  0x00007ffff4eb1c39 in QCoreApplication::notifyInternal2(QObject*, QEvent*) ()
    at /usr/lib/libQt5Core.so.5
#6  0x00007ffff4eb4ccc in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) ()
    at /usr/lib/libQt5Core.so.5
#7  0x00007ffff4f059d4 in  () at /usr/lib/libQt5Core.so.5
#8  0x00007ffff47703cf in g_main_context_dispatch () at /usr/lib/libglib-2.0.so.0
#9  0x00007ffff4771f89 in  () at /usr/lib/libglib-2.0.so.0
#10 0x00007ffff4771fce in g_main_context_iteration () at /usr/lib/libglib-2.0.so.0
#11 0x00007ffff4f04fc9 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib/libQt5Core.so.5
#12 0x00007ffff4eb08cc in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) ()
    at /usr/lib/libQt5Core.so.5
#13 0x00007ffff4cf9eb9 in QThread::exec() () at /usr/lib/libQt5Core.so.5
#14 0x00007ffff4d03f65 in  () at /usr/lib/libQt5Core.so.5
#15 0x00007ffff46eba9d in start_thread () at /usr/lib/libpthread.so.0
#16 0x00007ffff42ebb23 in clone () at /usr/lib/libc.so.6

Arch Linux 4.19.2-arch1-1-ARCH aur/telegram-desktop-dev 1.4.7-1

[ilya-fedin]

Any progress? I am very tired of these permanent crashes.

[flash207111]

Now I just to use telegram app from flatpak.

[ilya-fedin]

But this problem is everywhere ... In Arch packages, in the version on the official website and in Flatpak packages. I am currently using a version from Flatpak and Telegram is constantly crashing, because I have a not very stable 3G connection (the only way to connect to the Internet at home).

[PedroHLC]

@ilya-fedin use this fork:
https://aur.archlinux.org/packages/kepka-git

[ilya-fedin]

@PedroHLC it is a bad fork with bad developers and has the same problem

[rg4github]

Could it be that this issue is not with the app but with Qt itself?

I'm troubleshooting a crash in MythTV's web browser, which looks eerily similar (the reason I found this post):

Thread 39 "QNetworkAccessM" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ff26a7fc700 (LWP 28582)]
0x00007ff2ac5bf0e8 in ?? () from /lib64/libQt5Network.so.5
(gdb) bt
#0  0x00007ff2ac5bf0e8 in  () at /lib64/libQt5Network.so.5
#1  0x00007ff2ac5bda39 in  () at /lib64/libQt5Network.so.5
#2  0x00007ff2abf1dda6 in QObject::event(QEvent*) () at /lib64/libQt5Core.so.5
#3  0x00007ff2afaba285 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () at /lib64/libQt5Widgets.so.5
#4  0x00007ff2afac19a0 in QApplication::notify(QObject*, QEvent*) () at /lib64/libQt5Widgets.so.5
#5  0x00007ff2abef4ec6 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () at /lib64/libQt5Core.so.5
#6  0x00007ff2abef809b in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) ()
    at /lib64/libQt5Core.so.5
#7  0x00007ff2abf45807 in  () at /lib64/libQt5Core.so.5
#8  0x00007ff2a6b7c06d in g_main_context_dispatch () at /lib64/libglib-2.0.so.0
#9  0x00007ff2a6b7c438 in  () at /lib64/libglib-2.0.so.0
#10 0x00007ff2a6b7c4d0 in g_main_context_iteration () at /lib64/libglib-2.0.so.0
#11 0x00007ff2abf45593 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) ()
    at /lib64/libQt5Core.so.5
#12 0x00007ff2abef3e0b in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () at /lib64/libQt5Core.so.5
#13 0x00007ff2abd5be86 in QThread::exec() () at /lib64/libQt5Core.so.5
#14 0x00007ff2abd652fb in  () at /lib64/libQt5Core.so.5
#15 0x00007ff2b03c458e in start_thread () at /lib64/libpthread.so.0
#16 0x00007ff2ab8a36a3 in clone () at /lib64/libc.so.6
(gdb)

The (unrelated) app was compiled from scratch on Fedora 29, so Qt run time definitely matches the version it was compiled against. For what it's worth: network stability is not the issue for me. I get these crashes depending on the web pages I'm viewing, with some reproducing this consistently (e.g. CNN).

Just throwing another data point out as to the possible origin.

[john-preston]

@rg4github Yes, it looks like that. I couldn't find a place in my code where I wrongly delete the QNetworkReply and can cause such crash.

[rg4github]

I'm finding more bug unrelated bug reports pointing to what appears to be the same issue. This one is nicely detailed, and once again on Fedora 29:

Bug 1663726 - Discover 5.14.4 crashed when clicking on Checking for updates involving flatpak

The submitter of that bug seems to thinks it's a problem with the app, but the number of reports pointing to this area of code in Qt is starting to get disconcerting.

[Aokromes]

this bug is still valid?

[Aokromes]

no answer after 1 month, if this bug is still valid, open a new ticket with one updated telegram version downloaded from desktop.telegram.org or github.com