Bug 1708621
Summary: | GCC 9.1 compiler regression while building Telegram Desktop | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Vitaly <vitaly> |
Component: | gcc | Assignee: | Jakub Jelinek <jakub> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 30 | CC: | davejohansen, dmalcolm, ego.cordatus, fweimer, jakub, jwakely, lav, law, mpolacek, msebor, nickc, vascom2 |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2019-09-21 16:32:24 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Vitaly
2019-05-10 11:54:32 UTC
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). Fixed in 9.2.1-1. |