| View previous topic :: View next topic |
| Author |
Message |
Perfect Gentleman
Veteran
Joined: 18 May 2014
Posts: 1249
|
 Posted: Thu Nov 30, 2017 1:34 pm Post subject: [Solved] Chromium-63 is unstable with Clang. WTF? |
 |
|
I've built Chromium-63 with Clang-5. It's so unstable: extensions are unloading, pages are whoop-ing and oops-ing. But when built with GCC-7 it works as good as always. It's becoming more interesting as Chromium-62 built with Clang-5 was stable too. WTF could it be?
Last edited by Perfect Gentleman on Thu Dec 07, 2017 4:03 pm; edited 1 time in total |
|
| Back to top |
|
 |
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21642
|
| Posted: Fri Dec 01, 2017 3:23 am Post subject: |
|
|
Based on the limited information available, and assuming that clang-5 is not horribly buggy, the most likely explanation is that Chromium has code that invokes undefined behaviour, that gcc-7 compiles that code in a way that produces good results, and that clang-5 compiles that code in a way that produces bad results. If this is the explanation, then neither compiler is wrong, since the standard provides that the compiler has tremendous freedom in how to handle undefined behaviour. I recall reading a few months back about a Chromium crash that was traced to undefined behaviour in evaluating side effects. The code involved a smart pointer, but the below fragment expresses the same general flow: | Code: | char *p = some_data;
f((p = nullptr, 0), *p);
|
clang evaluated arguments left-to-right (if I recall correctly), producing this translation: | Code: | char *p = some_data;
p = nullptr;
auto arg0 = 0;
auto arg1 = *p;
f(arg0, arg1); |
gcc evaluated arguments right-to-left (again, if I recall correctly), producing this translation: | Code: | char *p = some_data;
auto arg1 = *p;
p = nullptr;
auto arg0 = 0;
f(arg0, arg1); |
The latter runs fine. The former is a nullptr dereference. The fix was for Chromium to use an explicit temporary, to force the ordering that gcc happened to prefer. |
|
| Back to top |
|
|
ct85711
Veteran
Joined: 27 Sep 2005
Posts: 1791
|
| Posted: Fri Dec 01, 2017 8:05 am Post subject: |
|
|
I recall reading a bug report recently, of where gcc-7.2.0 and clang-5 was generating different results, causing pyblake2 & portage to segfault. I am aware it is dealing about 2 completely different packages, but maybe it give you something to try.
Bug 638428 - sys-apps/portage-2.3.16 segfaults due to dev-python/pyblake2-1.0.0
In short, the more troublesome CFLAGS is -O3 and -ftree-vectorize... |
|
| Back to top |
|
|
Perfect Gentleman
Veteran
Joined: 18 May 2014
Posts: 1249
|
| Posted: Fri Dec 01, 2017 8:43 am Post subject: |
|
|
| I have all packages built with -O2 and -ftree-vectorize. All of them work stable. I see if Inox-63 is built with Clang then try again. The latest Chrome-63 is built with Clang-6. Maybe that's the reason. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Portage & Programming
