Tdesktop: Segmentation fault when using diacritics

Created on 7 Sep 2015 · 33Comments · Source: telegramdesktop/tdesktop

With a "brazil abnt2" keyboard layout under Linux (Gentoo), Telegram Desktop segfaults sometimes when trying to add diacritics through dead keys (like "á, ã, é"). Unfortunately this happens very unreliably, so it is somewhat hard to reproduce. A reliable way of causing a segfault that is very likely related to the one that happens arbitrarily, though, is using "reply" on a message, and on the very first character of the reply typing something through a dead key (for example, "^" through ^ + SPACE, or an accented letter.

I am using Telegram Desktop downloaded from the website, not compiled by myself, so I don't have all the debug information. I ran it with GDB and reproduced the bug, leading to this trace:

(gdb) bt full
#0  0x0000000000000000 in ?? ()
No symbol table info available.
#1  0x0000000000a85d4b in QApplication::notify(QObject*, QEvent*) ()
No symbol table info available.
#2  0x0000000000000001 in ?? ()
No symbol table info available.
#3  0x00007fffffffc760 in ?? ()
No symbol table info available.
#4  0x0000000000000001 in ?? ()
No symbol table info available.
#5  0x00007ffff768b6d7 in ?? () from /usr/lib64/libxcb.so.1
No symbol table info available.
#6  0x00007ffff768b8d6 in xcb_flush () from /usr/lib64/libxcb.so.1
No symbol table info available.
#7  0x0000000000dee5ff in QXcbBackingStore::flush(QWindow*, QRegion const&, QPoint const&) ()
No symbol table info available.
#8  0x3ff0000000000000 in ?? ()
No symbol table info available.
#9  0x00007ffff64fe640 in ?? () from /lib64/libc.so.6
No symbol table info available.
#10 0x0000000000000018 in ?? ()
No symbol table info available.
#11 0x0000000000000000 in ?? ()
No symbol table info available.

A friend of mine has confirmed the bug under similar circumstances, using Arch Linux.

I can try to provide more info if needed, or if the bug turns out to be harder to reproduce than thought.

bug linux

Source

tarcisioe

Most helpful comment

@tarcisioe I receive the backtrace from crash reports, but the crash is not the problem — the unfocused window is. Ok, thanks, I'll try i3.

john-preston on 23 Jun 2016

🎉1 👍1

All 33 comments

Found another related way to segfault: open a preview of media (either of a link to an image or a sent image), close it and insert something through a dead key.

One thing I noticed: the segfault always happens when a dead key is used but the cursor is NOT currently in any textbox. Actually, when you use reply, or open and close a media window, the cursor does NOT go back to the message textbox. It appears that pressing a letter makes the cursor jump back to it and then insert the letter pressed. However this is done in code, it appears to handle dead keys poorly, leading to the segfault.

tarcisioe on 9 Sep 2015

This should be fixed with https://github.com/telegramdesktop/tdesktop/commit/00c9d16925762b3ce2d0967ca7725beafd500a4d

auchri on 26 Sep 2015

@tarcisioe please check 0.9.3 dev version to confirm that it was fixed.

telegramdesktop on 4 Oct 2015

I can confirm it is fixed in 0.9.3 dev. Could not reproduce as described anymore. Also, thanks, it was a quite maddening one!

tarcisioe on 6 Oct 2015

I am sorry to take back what I have said, but the bug is now just happening sometimes. When I first tried it didn't, but right now I am able to reproduce it again, except that sometimes it doesn't happen.

The way to reproduce it is still look at a picture preview and then exit it by pressing ESC or clicking anywhere. When I do this, if the cursor is blinking on the message field it does NOT segfault, but sometimes it isn't and then the segfault happens as before. Curious thing is that when typing, if I just type in characters without diacritics, the cursor is solid, does not blink at all, and the software segfaults as soon as I type in a diacritic.

tarcisioe on 7 Oct 2015

Forgot to mention that the segfault that happened related to trying to reply does not happen anymore (at all, tried to reproduce over 10 times, couldn't), only the one related to the image preview does (still almost everytime).

tarcisioe on 7 Oct 2015

@tarcisioe Well, I did not fix the segfault itself, it is something in Qt, but it happens when window does not fully regain focus, so I tried to activate it manually. Looks like it still does not get activated after the photo viewer.

telegramdesktop on 7 Oct 2015

Just updated to 0.9.8 and it seems there is a regression, the bug when Reply is used is back. Steps are the same as usual:

Right click on a message and select reply.
Type in a letter with a diacritic (the cursor focus is, again, not on the text box)

tarcisioe on 28 Oct 2015

Can confirm this also happens on 0.9.15, with Arch Linux 4.2.5-1-ARCH x86_64, using es keyboard layout and i3wm.

Here is the catchsegv log: telegram.txt

roobre on 29 Dec 2015

Confirmed on 0.9.15 (stable channel) on Debian 8 and Arch, keyboard layout de (deadkeys), window manager bspwm.

Lesik on 31 Dec 2015

Can reconfirm with 4.4.5-1-ARCH, Telegram 0.9.33.

I've also observed the crashes happen when a picture has just been sent.

roobre on 22 Mar 2016

Can reconfirm into Telegram 0.9.33 downloaded using AUR.

scenarios:

reply a message using a diacritics: crash

reply a message witout diacritics.

type a message with diacritics after a reply: crash

Output in gdb:

Thread 1 "telegram-deskto" received signal SIGSEGV, Segmentation fault.
0x000000000148e540 in ?? ()

Ziul on 30 Mar 2016

Sitll present on Telegram 0.9.46 (aur/telegram-desktop-bin-dev). Diacritics typed (even before sending) after a reply or an image crashes the program.

Linux Workaroo 4.5.2-1-ARCH #1 SMP PREEMPT Thu Apr 21 18:21:27 CEST 2016 x86_64 GNU/Linux

roobre on 11 May 2016

On Xubuntu 16.04, keyboard layout Brazil ABNT2, I'm unable to use accents at all on Telegram 0.9.49. I guess you guys have disabled accents in order to prevent the app from crashing?

brwolfgang on 12 Jun 2016

@brwolfgang No, nothing was disabled specifically.

john-preston on 12 Jun 2016

@john-preston that's odd, I can use them on every other program, but not on Telegram.

brwolfgang on 12 Jun 2016

This is still happening with replies in version 0.9.52 and it is driving me crazy!

cauebs on 20 Jun 2016

@cauebs when you press Reply and start typing the words, does the cursor blink in the message input field? Because crashes are somehow Qt-related, and as I see they happen when an unfocused input field starts to receive compose keys input. I can't reproduce that myself in Manjaro Xfce :( Which DE and version do you use? Which keyboard input layout? So I have some questions:

Does the cursor blink after the Reply is pressed? (as I understand in the not-focused input field it won't blink)
Do the letters appear there before it crashes? (for example, if you choose english keyboard layout and just type english letters -- without dead keys, compose keys, accents etc) does it work fine with english letters?
Does it crash only when you use some complex input method (like dead keys or compose keys)?

Can you please submit a crash report (which will be offered when it crashed and then launched again) and copy a "Crash Report Tag" here (it will be shown in the crash report window).

john-preston on 23 Jun 2016

@john-preston Your question was not directly to me, but since I have posted the issue in the first place, I'll give you the answers from my system to try and help with what I can.

I am using i3 on Gentoo and my keyboard layout is Dvorak with a few personal modifications. Several friends of mine have the same issue in Arch Linux with a default Brazilian ABNT2 layout. Apparently the issue does not have to do with layouts, but with the presence of dead keys for typing diacritics. I can type ç for example, because I have a key that inputs that directly.

The cursor not blinking in the input field is a constant between every case: when I try to use reply, when I try do edit a message and when I leave an image preview. In fact sometimes it helps me remember that the crash is going to happen if I don't click the input field again. Indeed if I do, there is no crash.
Every letter that does not cause a crash does appear in the input field. Even though it initially appears as if it is not focused, the letters are, in fact, entered, but the cursor is solid, never blinking until I click the field to focus it. If I do that, as I said, no crashes ever happen, I can input diacritics as normal.
The issue happens (for me at least), only when I use a dead key. I can enter many non-english characters, such as ç or ß, and I can input stuff that I need to use Alt Gr or Shift to input, such as \.

I've sent a crash report, tag 5e5fca06-9289-a85c-0fa7d773-055ca304. Really hoping to see this fixed. The crash reporter made the bug a bit more annoying in fact, since Telegram Desktop starts VERY fast, but the crash reporter added a delay before it opening. Before it was more like I accidentally minimized the window, so it was quite minor. Also, thanks for looking into it.

tarcisioe on 23 Jun 2016

@tarcisioe Thank you for the info!

I think I even found the Qt code line that crashes (sending an event to "focusObject" which is "nullptr").

I can fix this (just not sending the event) and it will fix the crash, but just that — the dead key sequences won't appear in the field at all. Much better will be to fix the un-focus problem.

This has something to do with the popup menu: it takes the focus from the window, but when it gets destroyed, it doesn't return the focus to the main window. I even call the activation method when popup menu gets destroyed, but it still doesn't work :/ I guess I need to reproduce that somehow.

john-preston on 23 Jun 2016

@tarcisioe I'll try to install Arch Linux in Parallels, hope it will reproduce there. What DE should I use to (hopefully) reproduce the problem? (what DE are your friends with this issue in Arch Linux use?)

john-preston on 23 Jun 2016

@tarcisioe And also — do you press Reply by mouse, or select it by keyboard and press Enter? just to know.

john-preston on 23 Jun 2016

@john-preston I do press Reply by mouse (and so does @cauebs, who uses Antergos Linux and i3 as the WM as he told me). I don't remember anyone who had the issue who didn't use i3, but I remember vaguely a friend of mine having the same issue in XFCE. Remember that the issue is also caused by using Edit, or viewing an image on the overlay viewer and exiting it by clicking anywhere, or by pressing Esc (at least the symptoms are exactly the same).

I can try to provide more useful information, such as a gdb backtrace, I just don't have Telegram Desktop built with debug symbols, as far as I know (I always use the dev (now alpha) version, donwnloaded from the official webpage).

tarcisioe on 23 Jun 2016

@tarcisioe I receive the backtrace from crash reports, but the crash is not the problem — the unfocused window is. Ok, thanks, I'll try i3.

john-preston on 23 Jun 2016

🎉1 👍1

Hi there, finally this is getting some attention! Thank you @john-preston!
I can confirm I use Arch + i3 too, with the latest telegram-desktop version. Don't hesitate to ask for more details if you need to.

roobre on 23 Jun 2016

Thank you @john-preston. I still confirm the crash on Mint and Arch. Both using i3 and keyboard setup to ABNT2 (Brazil default). Crash do not happens with Cinnamon 2.4.8.

Reproduce crash:

right click on a msg and select reply
type a word with dead key that isn't inserted by only one key, like áéíóúãõ
the crash occurs when the second key is pressed

Opening Telegram by terminal, when crash occurs, it raises the message:

QTextCursor::setPosition: Position '8388607' out of range
QTextCursor::setPosition: Position '8388607' out of range
Segmentation fault

If the word/character is pasted or you type the message first and then select to reply the segmentation fault do not happens.

Ziul on 23 Jun 2016

@Ziul It doesn't happen for me in Mint + i3 :/