Description of problem: When Telegram Desktop built by GCC 9.0.1, everything works fine, but on GCC 9.1.1 it crashes after entering password: Thread 1 "telegram-deskto" received signal SIGSEGV, Segmentation fault. operator() () at /usr/src/debug/telegram-desktop-1.7.0-1.fc30.x86_64/Telegram/SourceFiles/data/data_session.cpp:3305 3305 *changesIn = (result > 0) Line cause this crash: https://github.com/telegramdesktop/tdesktop/blob/8af684f7f78f6c317323e1d1f2829e90e3bbd580/Telegram/SourceFiles/data/data_session.cpp#L3305 Version-Release number of selected component (if applicable): gcc-9.1.1-1.fc30.x86_64 How reproducible: Always. Steps to Reproduce: 1. Enable RPM Fusion repo. 2. Build this SRPM using GCC 9.1.1: http://koji.rpmfusion.org/kojifiles/packages/telegram-desktop/1.6.7/2.fc30/src/telegram-desktop-1.6.7-2.fc30.src.rpm 3. Login and run application. Actual results: Crash (SIGSEGV, segmentation fault). Expected results: Successful login. Additional info:
What do you mean by 9.0.1? There were were 16 rpm versions (9.0.1-0.1 through 9.0.1-0.16). Does it segfault if you recompile the corresponding TU (data_session.cpp) with -O0 instead of the default compile time flags? Any warnings?
> What do you mean by 9.0.1? There were were 16 rpm versions (9.0.1-0.1 through 9.0.1-0.16). Latest working version compiled with 9.0.1-0.10.fc30. Full mock's root log: http://koji.rpmfusion.org/kojifiles/packages/telegram-desktop/1.6.7/2.fc30/data/logs/x86_64/root.log > Does it segfault if you recompile the corresponding TU (data_session.cpp) with -O0 instead of the default compile time flags? With -O0 GCC 9.1.1 allocated all available RAM (16 GB) on linking stage and OOM killed this process. > Any warnings? No warnings when building this file.
Tested build with -O0 on Koji. It works. No crashes detected.
But you then built everything with -O0, or just the single TU and everything else with -O2? The point was to narrow down where to look at. I don't have F30 installed, can the crash be reproduced say just from F30 mock chroot using Xvfb or something similar? If you can build in mock and then test, what would be interesting is 1) bisection on which TU matters (everything built with -O2 and/or gcc 9.1.1, except one TU built with -O0 and/or gcc 9.0.1-0.10 works, everything built with -O0/9.0.1-0.10 except that one TU built with -O2/9.1.1-1 fails) 2) bisection which gcc change changed that (0.11 to 0.16) then preprocessed source of the corresponding TU with g++ command line.
> But you then built everything with -O0, or just the single TU and everything else with -O2? Everything with -O0 with disabled LTO optimizations. > I don't have F30 installed, can the crash be reproduced say just from F30 mock chroot using Xvfb or something similar? I tested on virtual machine too. It crashes. > 1) bisection on which TU matters (everything built with -O2 and/or gcc 9.1.1, except one TU built with -O0 and/or gcc 9.0.1-0.10 works, How can I do this in mock? > 2) bisection which gcc change changed that (0.11 to 0.16) I can check this.
> 2) bisection which gcc change changed that (0.11 to 0.16) Experimental test results: * 0.11 - passed; * 0.12 - passed; * 0.13 - passed; * 0.14 - passed; * 0.15 - crash. 0.14 is a last working version.
0.13 - 0.15 results for different tests/diffs: https://xvitaly.fedorapeople.org/gcc-exp.7z
If you could say setup 2 separate mock chroots, one with gcc 9.0.0-0.14 and one with 9.0.0-0.15, build in both, then make a copy of one of the build trees, copy half of *.o files from the 0.14 tree to 0.15 and touch them, in mock -r ... shell make again to relink, retest and depending on the outcome bisect to a particular *.o file. For that particular TU I'd like to see preprocessed source (if you add -save-temps to compilation of that TU and also the full command line).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90949
Fixed in 9.2.1-1.