Arch Linux

Possible dupe of  FS#76697 

Your logs say it dumps core. Does the trace reveal anything interesting? [1]

[1] https://wiki.archlinux.org/title/Debugging/Getting_traces

I got this from the last test:

[OpenH264] this = 0x0x7fffc161e180, Warning:Change QP Range from(0,51) to (12,42)
[OpenH264] this = 0x0x7fffc161e180, Warning:[Rc] iDid = 0,iContinualSkipFrames(3) is large
[OpenH264] this = 0x0x7fffc161e180, Warning:[Rc] iDid = 0,iContinualSkipFrames(6) is large
[OpenH264] this = 0x0x7fffc161e180, Warning:[Rc] iDid = 0,iContinualSkipFrames(9) is large
[OpenH264] this = 0x0x7fffc161e180, Warning:[Rc] iDid = 0,iContinualSkipFrames(12) is large
[OpenH264] this = 0x0x7fffc161e180, Warning:[Rc] iDid = 0,iContinualSkipFrames(3) is large
[OpenH264] this = 0x0x7fffc161e180, Warning:Actual input framerate 0,000000 is different from framerate in setting 8,000000, suggest to use other rate control modes

Thread 1 "telegram-deskto" received signal SIGSEGV, Segmentation fault.
__memcpy_sse2_unaligned () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:228
Downloading 0.03 MB source file /build/glibc/src/glibc/string/../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S
228 VMOVU (%rsi), %VEC(0)
(gdb)

Ugh, memory corruption. telegram seems a bit "crashy" lately. Is it feasible to enable "debug" build option @Svenstaro?

Good idea, done. telegram-desktop can definitely benefit from debug packages.

Also this is weird: It says SSE2 but uses VMOVU, an AVX instruction? No wonder it's not aligned. I wonder, Maxwell what's your CPU?

I got this from the last test:

[OpenH264] this = 0x0x7fffc161e180, Warning:Change QP Range from(0,51) to (12,42)
[OpenH264] this = 0x0x7fffc161e180, Warning:[Rc] iDid = 0,iContinualSkipFrames(3) is large
[OpenH264] this = 0x0x7fffc161e180, Warning:[Rc] iDid = 0,iContinualSkipFrames(6) is large
[OpenH264] this = 0x0x7fffc161e180, Warning:[Rc] iDid = 0,iContinualSkipFrames(9) is large
[OpenH264] this = 0x0x7fffc161e180, Warning:[Rc] iDid = 0,iContinualSkipFrames(12) is large
[OpenH264] this = 0x0x7fffc161e180, Warning:[Rc] iDid = 0,iContinualSkipFrames(3) is large
[OpenH264] this = 0x0x7fffc161e180, Warning:Actual input framerate 0,000000 is different from framerate in setting 8,000000, suggest to use other rate control modes

Thread 1 "telegram-deskto" received signal SIGSEGV, Segmentation fault.
__memcpy_sse2_unaligned () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:228
Downloading 0.03 MB source file /build/glibc/src/glibc/string/../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S
228 VMOVU (%rsi), %VEC(0)
(gdb)

@Svenstaro This is the CPU information:

[user@localhost]$ lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Address sizes: 36 bits physical, 48 bits virtual
Byte Order: Little Endian
CPU(s): 8
On-line CPU(s) list: 0-7
Vendor ID: GenuineIntel
Model name: Intel(R) Core(TM) i7-2670QM CPU @ 2.20GHz
CPU family: 6
Model: 42
Thread(s) per core: 2
Core(s) per socket: 4
Socket(s): 1
Stepping: 7
CPU(s) scaling MHz: 82%
CPU max MHz: 3100.0000
CPU min MHz: 800.0000
BogoMIPS: 4391.92
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ht tm pbe syscall nx rdtscp lm
constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2
ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer xsave avx lahf_lm epb pti tpr_shadow vnmi flexpriority ept vpid
xsaveopt dtherm ida arat pln pts
Virtualization features:
Virtualization: VT-x
Caches (sum of all):
L1d: 128 KiB (4 instances)
L1i: 128 KiB (4 instances)
L2: 1 MiB (4 instances)
L3: 6 MiB (1 instance)
NUMA:
NUMA node(s): 1
NUMA node0 CPU(s): 0-7
Vulnerabilities:
Itlb multihit: KVM: Mitigation: VMX disabled
L1tf: Mitigation; PTE Inversion; VMX conditional cache flushes, SMT vulnerable
Mds: Vulnerable: Clear CPU buffers attempted, no microcode; SMT vulnerable
Meltdown: Mitigation; PTI
Mmio stale data: Unknown: No mitigations
Retbleed: Not affected
Spec store bypass: Vulnerable
Spectre v1: Mitigation; usercopy/swapgs barriers and __user pointer sanitization
Spectre v2: Mitigation; Retpolines, STIBP disabled, RSB filling, PBRSB-eIBRS Not affected
Srbds: Not affected
Tsx async abort: Not affected
[user@localhost]$

This issue stills with:

Telegram Version: 4.5.3-1
KDE Plasma Version: 5.26.5
KDE Frameworks Version: 5.101.0
Qt Version: 5.15.8
Kernel Version: 6.1.4-arch1-1 (64-bit)
Graphics Platform: Wayland

I confirm the issue to be still there with 4.5.3-1.
Here is the core dump trace log:
https://pastebin.com/fh4eyhJL

The official app developers claim the issue to be fixed with the following patchset:

https://github.com/telegramdesktop/tdesktop/issues/25780#issuecomment-1402796924

Is there a way to apply it on next builds?

It could be done but we're not going to apply it to our normal Qt build as that would potentially affect all other packages relying on Qt. What we should try to do instead is use a static qt build which we patch and then link to tgdesktop. However this is fairly involved and I don't have time to attempt this right now. If you can get it to work I'll be glad to change the package with your findings.

Attached diff and src.tar.gz build a patched libQt6OpenGL.so.6 then places it in /usr/lib/telegram-desktop and adds an rpath to the telegram binary pointing to the directory.
Hopefully this should at least test if the patch upstream recomended, fixes the issue.

Thanks loqs, that's actually very helpful. However, I wonder whether we shouldn't perhaps just use the full patch set that upstream uses if we're already going this way? The patches are here: https://github.com/desktop-app/patches/tree/master/qtbase_6_4_2 and they really do appear to be using them all in their official builds:
1) https://github.com/telegramdesktop/tdesktop/blob/de11987312798bda5dea716ea5210adf807e20aa/Telegram/build/prepare/prepare.py#L1303
2) https://github.com/telegramdesktop/tdesktop/blob/cd85c4911c7ad39754b7c343ae60a0369ee03dc6/Telegram/build/docker/centos_env/Dockerfile#L695

What do you think?

I went ahead and tried to produce a Telegram that only uses the statically linked Qt6 in the version and with the patches that upstream expects. I think this is probably the best way forward until by some kind of magic upstream becomes compatible with mainstream Qt6.

However, I couldn't get it to compile as it doesn't find the static installation. I don't currently have more time to spend on it. Maybe you could take a look.

I was able to get it to the final link. The disabling of LTO was to speed up rebuilds during testing, the switch to make was due to ninja not having a big enough buffer to print the link failure cause.
I have no idea why it is failing to link.

The patches are for building stuff with qmake, they are irrelevant here.

@arojas as the patches are irrelevant they should not be the cause of the build failure? So this log with them in use should still be relevant, I hope. Any thoughts on the build failure?
Edit:
Updated diff, with patches removed. No change in build output.

The failure has nothing to do with Qt, it's caused by the change in CMAKE_BUILD_TYPE.

@arojas Thank You the -DNEDEBUG CMAKE_BUILD_TYPE=Release adds removed cld3's runtime checking that failed to link.

Adjusted Qt build to be closer to upstream's.

I stuck a package into [community-testing]. Can you guys check?

Hi.
telegram-desktop 4.6.1-2 doesn't start on GNOME (Wayland) due to missing plugin: xcb, 4.6.1-1 worked fine.

telegram-desktop 4.6.2-1, run in alacritty (GNOME, Wayland):
```
$ export QT
$ LANG=en_US.UTF-8 telegram-desktop

qt.qpa.plugin: Could not find the Qt platform plugin "wayland" in ""
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

Available platform plugins are: xcb.

Аварийный останов (стек памяти сброшен на диск)

$ env | grep QT
QT_QPA_PLATFORMTHEME=qt6ct
QT_QPA_PLATFORM=wayland
```

(Why the last message after telegram-desktop was terminated is printed in Russian, I don't know.)

I'm reverting this back to using system qt6. loqs, if you have some time to investigate the various issues people reported with the static qt6 build, I'd much appreciate but I don't currently have more time to spend on this.

Same here, telegram-desktop 4.6.2-2 crashes when you enable video in your call :D

KDE Plasma 5.26.5
KDE Frameworks 5.102.0
Qt 5.15.8
Kernel 6.1.11

Still happening with latest pkg?