Re: [PATCH] switch to clang-9 in Linux/travis-ci builds
On Sun, Jun 14, 2020 at 01:20:43AM +0500, ??? wrote: > I added "-O1" to travis builds. > Can we apply it until a better solution will be found ? Applied, thank you Ilya. Willy
Re: [PATCH] switch to clang-9 in Linux/travis-ci builds
I added "-O1" to travis builds.
Can we apply it until a better solution will be found ?
пт, 12 июн. 2020 г. в 21:40, Илья Шипицин :
>
>
> пт, 12 июн. 2020 г. в 21:09, Willy Tarreau :
>
>> On Fri, Jun 12, 2020 at 08:57:44PM +0500, ??? wrote:
>> > ??, 12 ???. 2020 ?. ? 20:46, Willy Tarreau :
>> >
>> > > On Fri, Jun 12, 2020 at 08:11:52PM +0500, ??? wrote:
>> > > > > Has it ever reported a *real* issue ? I mean, we've been working
>> around
>> > > > >
>> > > >
>> > > >
>> > > > https://github.com/haproxy/haproxy/issues/96
>> > > > https://github.com/haproxy/haproxy/issues/104
>> > > > https://github.com/haproxy/haproxy/issues/106
>> > > > https://github.com/haproxy/haproxy/issues/111
>> > >
>> > > Well only two above are the address sanitizer, one is valgrind and the
>> > > other one is the thread sanitizer.
>> > >
>> > > > and I hope that William Lallemand also found and fixed about 5 bugs
>> > > > detected by travis + asan
>> > >
>> > > Maybe.
>> > >
>> > > In that case at least we should run it at -O1. It's at -O2 that it
>> > > produces bogus code from what I'm seeing. And given that the docs
>> > > also suggest -O1 to get a usable backtrace, it's possible that it's
>> > > rarely tested in combination with -O2. But anyway I really *hate*
>> > > seeing compilers silently emit bad code, especially when it happens
>> > > when asking them to detect more anomalies!
>> > >
>> >
>> > I may try to report it. Is there small repro code ?
>>
>> Sadly not, as usual with bad code. It dies in b_alloc_margin() with a
>> NULL "buf" (long after having successfully dereferenced it) when getting
>> the first H2 request. Putting a printf() in the caller (h2_get_buf) is
>> usually enough to stop the bug. However a printf in the caller doesn't
>> change anything, which could indicate that we may succeed in isolating
>> these functions. I saw it crash when buf was assigned to rbx register,
>> maybe it's occasionally clobbered by their functions, I don't know.
>> I've spent way too much time on it now. I may try to elaborate a repro
>> later but I have way more important things to do than trying to debug
>> an experimental tool that's broken in other areas anyway :-/
>>
>
>
> I'll play with recent builds on travis switching -O2 <--> -O1
>
>
>>
>> Willy
>>
>
From fc74deb80c15144a6649729a4ec92498f606206f Mon Sep 17 00:00:00 2001
From: Ilya Shipitsin
Date: Sun, 14 Jun 2020 01:08:37 +0500
Subject: [PATCH] CI: travis-ci: "-O1" for clang builds
it turned out that clang asan fails with -O2 option
better solution yet to be found
ML: https://www.mail-archive.com/haproxy@formilux.org/msg37621.html
---
.travis.yml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/.travis.yml b/.travis.yml
index 809c2292f..6199bc881 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -119,7 +119,7 @@ install:
script:
- if [ "${CC%-*}" = "clang" ]; then export FLAGS="$FLAGS USE_OBSOLETE_LINKER=1" DEBUG_CFLAGS="-g -fsanitize=address" LDFLAGS="-fsanitize=address"; fi
- make -C contrib/wurfl
- - make -j3 CC=$CC V=1 ERR=1 TARGET=$TARGET $FLAGS DEBUG_CFLAGS="$DEBUG_CFLAGS" LDFLAGS="$LDFLAGS" ADDLIB="-Wl,-rpath,$SSL_LIB" 51DEGREES_SRC="$FIFTYONEDEGREES_SRC" EXTRA_OBJS="$EXTRA_OBJS" $DEBUG_OPTIONS
+ - make -j3 CC=$CC CPU_CFLAGS.generic="-O1" V=1 ERR=1 TARGET=$TARGET $FLAGS DEBUG_CFLAGS="$DEBUG_CFLAGS" LDFLAGS="$LDFLAGS" ADDLIB="-Wl,-rpath,$SSL_LIB" 51DEGREES_SRC="$FIFTYONEDEGREES_SRC" EXTRA_OBJS="$EXTRA_OBJS" $DEBUG_OPTIONS
- ./haproxy -vv
- if [ "${TRAVIS_OS_NAME}" = "linux" ]; then ldd haproxy; fi
- if [ "${TRAVIS_OS_NAME}" = "osx" ]; then otool -L haproxy; fi
--
2.26.2
Re: [PATCH] switch to clang-9 in Linux/travis-ci builds
пт, 12 июн. 2020 г. в 21:09, Willy Tarreau : > On Fri, Jun 12, 2020 at 08:57:44PM +0500, ??? wrote: > > ??, 12 ???. 2020 ?. ? 20:46, Willy Tarreau : > > > > > On Fri, Jun 12, 2020 at 08:11:52PM +0500, ??? wrote: > > > > > Has it ever reported a *real* issue ? I mean, we've been working > around > > > > > > > > > > > > > > > > > https://github.com/haproxy/haproxy/issues/96 > > > > https://github.com/haproxy/haproxy/issues/104 > > > > https://github.com/haproxy/haproxy/issues/106 > > > > https://github.com/haproxy/haproxy/issues/111 > > > > > > Well only two above are the address sanitizer, one is valgrind and the > > > other one is the thread sanitizer. > > > > > > > and I hope that William Lallemand also found and fixed about 5 bugs > > > > detected by travis + asan > > > > > > Maybe. > > > > > > In that case at least we should run it at -O1. It's at -O2 that it > > > produces bogus code from what I'm seeing. And given that the docs > > > also suggest -O1 to get a usable backtrace, it's possible that it's > > > rarely tested in combination with -O2. But anyway I really *hate* > > > seeing compilers silently emit bad code, especially when it happens > > > when asking them to detect more anomalies! > > > > > > > I may try to report it. Is there small repro code ? > > Sadly not, as usual with bad code. It dies in b_alloc_margin() with a > NULL "buf" (long after having successfully dereferenced it) when getting > the first H2 request. Putting a printf() in the caller (h2_get_buf) is > usually enough to stop the bug. However a printf in the caller doesn't > change anything, which could indicate that we may succeed in isolating > these functions. I saw it crash when buf was assigned to rbx register, > maybe it's occasionally clobbered by their functions, I don't know. > I've spent way too much time on it now. I may try to elaborate a repro > later but I have way more important things to do than trying to debug > an experimental tool that's broken in other areas anyway :-/ > I'll play with recent builds on travis switching -O2 <--> -O1 > > Willy >
Re: [PATCH] switch to clang-9 in Linux/travis-ci builds
On Fri, Jun 12, 2020 at 08:57:44PM +0500, ??? wrote: > ??, 12 ???. 2020 ?. ? 20:46, Willy Tarreau : > > > On Fri, Jun 12, 2020 at 08:11:52PM +0500, ??? wrote: > > > > Has it ever reported a *real* issue ? I mean, we've been working around > > > > > > > > > > > > > https://github.com/haproxy/haproxy/issues/96 > > > https://github.com/haproxy/haproxy/issues/104 > > > https://github.com/haproxy/haproxy/issues/106 > > > https://github.com/haproxy/haproxy/issues/111 > > > > Well only two above are the address sanitizer, one is valgrind and the > > other one is the thread sanitizer. > > > > > and I hope that William Lallemand also found and fixed about 5 bugs > > > detected by travis + asan > > > > Maybe. > > > > In that case at least we should run it at -O1. It's at -O2 that it > > produces bogus code from what I'm seeing. And given that the docs > > also suggest -O1 to get a usable backtrace, it's possible that it's > > rarely tested in combination with -O2. But anyway I really *hate* > > seeing compilers silently emit bad code, especially when it happens > > when asking them to detect more anomalies! > > > > I may try to report it. Is there small repro code ? Sadly not, as usual with bad code. It dies in b_alloc_margin() with a NULL "buf" (long after having successfully dereferenced it) when getting the first H2 request. Putting a printf() in the caller (h2_get_buf) is usually enough to stop the bug. However a printf in the caller doesn't change anything, which could indicate that we may succeed in isolating these functions. I saw it crash when buf was assigned to rbx register, maybe it's occasionally clobbered by their functions, I don't know. I've spent way too much time on it now. I may try to elaborate a repro later but I have way more important things to do than trying to debug an experimental tool that's broken in other areas anyway :-/ Willy
Re: [PATCH] switch to clang-9 in Linux/travis-ci builds
пт, 12 июн. 2020 г. в 20:46, Willy Tarreau : > On Fri, Jun 12, 2020 at 08:11:52PM +0500, ??? wrote: > > > Has it ever reported a *real* issue ? I mean, we've been working around > > > > > > > > > https://github.com/haproxy/haproxy/issues/96 > > https://github.com/haproxy/haproxy/issues/104 > > https://github.com/haproxy/haproxy/issues/106 > > https://github.com/haproxy/haproxy/issues/111 > > Well only two above are the address sanitizer, one is valgrind and the > other one is the thread sanitizer. > > > and I hope that William Lallemand also found and fixed about 5 bugs > > detected by travis + asan > > Maybe. > > In that case at least we should run it at -O1. It's at -O2 that it > produces bogus code from what I'm seeing. And given that the docs > also suggest -O1 to get a usable backtrace, it's possible that it's > rarely tested in combination with -O2. But anyway I really *hate* > seeing compilers silently emit bad code, especially when it happens > when asking them to detect more anomalies! > I may try to report it. Is there small repro code ? > > Willy >
Re: [PATCH] switch to clang-9 in Linux/travis-ci builds
On Fri, Jun 12, 2020 at 08:11:52PM +0500, ??? wrote: > > Has it ever reported a *real* issue ? I mean, we've been working around > > > > > https://github.com/haproxy/haproxy/issues/96 > https://github.com/haproxy/haproxy/issues/104 > https://github.com/haproxy/haproxy/issues/106 > https://github.com/haproxy/haproxy/issues/111 Well only two above are the address sanitizer, one is valgrind and the other one is the thread sanitizer. > and I hope that William Lallemand also found and fixed about 5 bugs > detected by travis + asan Maybe. In that case at least we should run it at -O1. It's at -O2 that it produces bogus code from what I'm seeing. And given that the docs also suggest -O1 to get a usable backtrace, it's possible that it's rarely tested in combination with -O2. But anyway I really *hate* seeing compilers silently emit bad code, especially when it happens when asking them to detect more anomalies! Willy
Re: [PATCH] switch to clang-9 in Linux/travis-ci builds
пт, 12 июн. 2020 г. в 20:01, Willy Tarreau : > On Fri, Jun 12, 2020 at 07:52:48PM +0500, ??? wrote: > > it should be detectable using > > > > #if defined(__has_feature)# if __has_feature(address_sanitizer)// > > code that builds only under AddressSanitizer# endif#endif > > OK that could be useful indeed, thanks! > > > I agree to remove asan from travis. However, I still find it somewhat > > useful, I would add daily github action job with asan enabled (in the > > way it would not bother anymore). > > Has it ever reported a *real* issue ? I mean, we've been working around > https://github.com/haproxy/haproxy/issues/96 https://github.com/haproxy/haproxy/issues/104 https://github.com/haproxy/haproxy/issues/106 https://github.com/haproxy/haproxy/issues/111 and I hope that William Lallemand also found and fixed about 5 bugs detected by travis + asan > its bugs but beyond this ? This looks like totally experimental junk to > me when I see how simple code paths get ruined. I've stopped looking at > travis reports again because when I start my browser, it loads with a > red tab and I already predict it will be on the clang builds. Having > something constantly cry wolf serves no purpose. Also, it seems to be > highly sensitive to the initialization ordering and randomly fails > during startup if you build without USE_OBSOLETE_LINKER. That's a real > PITA which currently only adds noise. > > Willy >
Re: [PATCH] switch to clang-9 in Linux/travis-ci builds
On Fri, Jun 12, 2020 at 07:52:48PM +0500, ??? wrote: > it should be detectable using > > #if defined(__has_feature)# if __has_feature(address_sanitizer)// > code that builds only under AddressSanitizer# endif#endif OK that could be useful indeed, thanks! > I agree to remove asan from travis. However, I still find it somewhat > useful, I would add daily github action job with asan enabled (in the > way it would not bother anymore). Has it ever reported a *real* issue ? I mean, we've been working around its bugs but beyond this ? This looks like totally experimental junk to me when I see how simple code paths get ruined. I've stopped looking at travis reports again because when I start my browser, it loads with a red tab and I already predict it will be on the clang builds. Having something constantly cry wolf serves no purpose. Also, it seems to be highly sensitive to the initialization ordering and randomly fails during startup if you build without USE_OBSOLETE_LINKER. That's a real PITA which currently only adds noise. Willy
Re: [PATCH] switch to clang-9 in Linux/travis-ci builds
пт, 12 июн. 2020 г. в 19:31, Willy Tarreau : > Hi Ilya, > > On Mon, Mar 16, 2020 at 10:49:26AM +0100, Tim Düsterhus wrote: > > Ilya, > > > > Am 16.03.20 um 07:52 schrieb ???: > > > we use clang because of its address sanitizer. I found gcc asan more > noisy > > > and less usable. > > Going back to this, I spent the whole day trying to figure what broke > on travis to finally find that it's clang's broken ASAN which generates > bad code at -O2. Function b_alloc_margin() sees its "buf" pointer change > from valid to null in the middle of the function while not being assigned. > Just printing it or assigning it from itself is enough to stop the bug, I > suspect it's doing something wrong with the register where it placed the > pointer. I'm really fed up with this bogus address sanitizer, it has wasted > a huge amount of time and patience trying to find bugs that did not exist > and > because of this yet-another fake one I haven't finished addressing a real > one :-( > > Could we once for all disable this monster crap and mention in the commit > message that it must never be turned on until it stops doing stupid things > ? > > Sadly I couldn't find a way to detect it from within the code. I'd like > to prevent haproxy from being built with this crap without explicit > debug flags because the wrong code it produces triggers segfaults at > runtime in random locations and as such it's extremely dangerous. There's > definitely a risk that some people are not aware of its breakage and would > build haproxy with it and run it on their production, which is scary. If > anyone knows how to reliably detect it (ideally at build time), feel free > to suggest! > it should be detectable using #if defined(__has_feature)# if __has_feature(address_sanitizer)// code that builds only under AddressSanitizer# endif#endif I agree to remove asan from travis. However, I still find it somewhat useful, I would add daily github action job with asan enabled (in the way it would not bother anymore). > Thanks, > Willy >
Re: [PATCH] switch to clang-9 in Linux/travis-ci builds
Hi Ilya, On Mon, Mar 16, 2020 at 10:49:26AM +0100, Tim Düsterhus wrote: > Ilya, > > Am 16.03.20 um 07:52 schrieb ???: > > we use clang because of its address sanitizer. I found gcc asan more noisy > > and less usable. Going back to this, I spent the whole day trying to figure what broke on travis to finally find that it's clang's broken ASAN which generates bad code at -O2. Function b_alloc_margin() sees its "buf" pointer change from valid to null in the middle of the function while not being assigned. Just printing it or assigning it from itself is enough to stop the bug, I suspect it's doing something wrong with the register where it placed the pointer. I'm really fed up with this bogus address sanitizer, it has wasted a huge amount of time and patience trying to find bugs that did not exist and because of this yet-another fake one I haven't finished addressing a real one :-( Could we once for all disable this monster crap and mention in the commit message that it must never be turned on until it stops doing stupid things ? Sadly I couldn't find a way to detect it from within the code. I'd like to prevent haproxy from being built with this crap without explicit debug flags because the wrong code it produces triggers segfaults at runtime in random locations and as such it's extremely dangerous. There's definitely a risk that some people are not aware of its breakage and would build haproxy with it and run it on their production, which is scary. If anyone knows how to reliably detect it (ideally at build time), feel free to suggest! Thanks, Willy
Re: [PATCH] switch to clang-9 in Linux/travis-ci builds
oops :)
Comment #4 on issue 323 by david...@chromium.org: boringssl fails on
travis-ci/clang-9
https://bugs.chromium.org/p/boringssl/issues/detail?id=323#c4
Looks like the issue is you've managed to convince it that your C compiler
is Clang and your C++ compiler is GCC.
-- The C compiler identification is Clang 9.0.1
-- Check for working C compiler: /usr/bin/clang
-- Check for working C compiler: /usr/bin/clang -- works
[...]
-- The CXX compiler identification is GNU 9.2.1
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
We use the same flags for the C and C++ compiler, since mixing them is
pretty rare, and it turns out our clang logic is based on the C++ compiler.
I'm guessing you've set the CC environment variable to clang or so? You
need to also point CXX to your clang++.
пн, 16 мар. 2020 г. в 16:02, Илья Шипицин :
>
>
> пн, 16 мар. 2020 г. в 14:54, Willy Tarreau :
>
>> On Mon, Mar 16, 2020 at 10:49:26AM +0100, Tim Düsterhus wrote:
>> > Ilya,
>> >
>> > Am 16.03.20 um 07:52 schrieb ???:
>> > > we use clang because of its address sanitizer. I found gcc asan more
>> noisy
>> > > and less usable.
>> >
>> > I believe you broke ASAN with clang-9 anyway, because the Travis
>> > configuration checks for 'clang':
>> >
>> https://github.com/haproxy/haproxy/blob/67b095e797a156ae27b7b52f6ccf57171717dd16/.travis.yml#L108
>> >
>> > It probably needs to read `if [ "$CC" = "clang*" ]` (unless I got my
>> > bash syntax wrong).
>>
>> Indeed. However it should be:
>>
>> if [ "${CC%-*}" = "clang" ]
>>
>
> it did not indicate any error. so it looked ok :)
>
>
>>
>> I'd like to focus on what's still broken (i.e. the abns seamless reload
>> test)
>> before adding more noise. It ought to be fixed but it is still random, it
>> even failed once on amd64. I definitely need to be able to reproduce it,
>> as
>> I was certain the two recent bugs fixed were the only ones responsible for
>> this.
>>
>
> sure
>
>
>>
>> Willy
>>
>
Re: [PATCH] switch to clang-9 in Linux/travis-ci builds
пн, 16 мар. 2020 г. в 14:54, Willy Tarreau :
> On Mon, Mar 16, 2020 at 10:49:26AM +0100, Tim Düsterhus wrote:
> > Ilya,
> >
> > Am 16.03.20 um 07:52 schrieb ???:
> > > we use clang because of its address sanitizer. I found gcc asan more
> noisy
> > > and less usable.
> >
> > I believe you broke ASAN with clang-9 anyway, because the Travis
> > configuration checks for 'clang':
> >
> https://github.com/haproxy/haproxy/blob/67b095e797a156ae27b7b52f6ccf57171717dd16/.travis.yml#L108
> >
> > It probably needs to read `if [ "$CC" = "clang*" ]` (unless I got my
> > bash syntax wrong).
>
> Indeed. However it should be:
>
> if [ "${CC%-*}" = "clang" ]
>
it did not indicate any error. so it looked ok :)
>
> I'd like to focus on what's still broken (i.e. the abns seamless reload
> test)
> before adding more noise. It ought to be fixed but it is still random, it
> even failed once on amd64. I definitely need to be able to reproduce it, as
> I was certain the two recent bugs fixed were the only ones responsible for
> this.
>
sure
>
> Willy
>
Re: [PATCH] switch to clang-9 in Linux/travis-ci builds
On Mon, Mar 16, 2020 at 10:49:26AM +0100, Tim Düsterhus wrote:
> Ilya,
>
> Am 16.03.20 um 07:52 schrieb ???:
> > we use clang because of its address sanitizer. I found gcc asan more noisy
> > and less usable.
>
> I believe you broke ASAN with clang-9 anyway, because the Travis
> configuration checks for 'clang':
> https://github.com/haproxy/haproxy/blob/67b095e797a156ae27b7b52f6ccf57171717dd16/.travis.yml#L108
>
> It probably needs to read `if [ "$CC" = "clang*" ]` (unless I got my
> bash syntax wrong).
Indeed. However it should be:
if [ "${CC%-*}" = "clang" ]
I'd like to focus on what's still broken (i.e. the abns seamless reload test)
before adding more noise. It ought to be fixed but it is still random, it
even failed once on amd64. I definitely need to be able to reproduce it, as
I was certain the two recent bugs fixed were the only ones responsible for
this.
Willy
Re: [PATCH] switch to clang-9 in Linux/travis-ci builds
Ilya, Am 16.03.20 um 07:52 schrieb Илья Шипицин: > we use clang because of its address sanitizer. I found gcc asan more noisy > and less usable. I believe you broke ASAN with clang-9 anyway, because the Travis configuration checks for 'clang': https://github.com/haproxy/haproxy/blob/67b095e797a156ae27b7b52f6ccf57171717dd16/.travis.yml#L108 It probably needs to read `if [ "$CC" = "clang*" ]` (unless I got my bash syntax wrong). Best regards Tim Düsterhus
Re: [PATCH] switch to clang-9 in Linux/travis-ci builds
пн, 16 мар. 2020 г. в 13:40, Willy Tarreau : > On Mon, Mar 16, 2020 at 12:51:20PM +0500, ??? wrote: > > From 5d5891166389dc03ab4fb63ca9edaa35feca8fcc Mon Sep 17 00:00:00 2001 > > From: Ilya Shipitsin > > Date: Mon, 16 Mar 2020 12:49:34 +0500 > > Subject: [PATCH] CI: switch BoringSSL back to clang-7 > > > > it turned out that BoringSSL is not prepared for clang-9 > > https://bugs.chromium.org/p/boringssl/issues/detail?id=323 > > > > until that issue is resolved, let us roll back to clang-7 > (...) > > -env: TARGET=linux-glibc BORINGSSL=yes CC=clang-9 > > +env: TARGET=linux-glibc BORINGSSL=yes CC=clang > > I already reverted that part however I switched back to not defining CC > as before the change. Is it OK ? > sure > > Willy >
Re: [PATCH] switch to clang-9 in Linux/travis-ci builds
On Mon, Mar 16, 2020 at 12:51:20PM +0500, ??? wrote: > From 5d5891166389dc03ab4fb63ca9edaa35feca8fcc Mon Sep 17 00:00:00 2001 > From: Ilya Shipitsin > Date: Mon, 16 Mar 2020 12:49:34 +0500 > Subject: [PATCH] CI: switch BoringSSL back to clang-7 > > it turned out that BoringSSL is not prepared for clang-9 > https://bugs.chromium.org/p/boringssl/issues/detail?id=323 > > until that issue is resolved, let us roll back to clang-7 (...) > -env: TARGET=linux-glibc BORINGSSL=yes CC=clang-9 > +env: TARGET=linux-glibc BORINGSSL=yes CC=clang I already reverted that part however I switched back to not defining CC as before the change. Is it OK ? Willy
Re: [PATCH] switch to clang-9 in Linux/travis-ci builds
пн, 16 мар. 2020 г. в 12:09, Willy Tarreau : > On Mon, Mar 16, 2020 at 11:52:27AM +0500, ??? wrote: > > ??, 16 ???. 2020 ?. ? 11:35, Willy Tarreau : > > > > > On Sun, Mar 15, 2020 at 10:54:56PM +0500, ??? wrote: > > > > ??, 14 ???. 2020 ?. ? 14:23, Willy Tarreau : > > > > > > > > > Hi Ilya, > > > > > > > > > > On Fri, Jan 24, 2020 at 11:46:45AM +0500, ??? wrote: > > > > > > Hello, > > > > > > > > > > > > let us use clang-9 instead of default clang-7 for linux builds. > > > > > > > > > > It seems I missed this one. Now applied carefully, we'll see. If it > > > > > causes new failures, we'll adjust accordingly. > > > > > > > > > > > > > BoringSSL is not happy > > > > https://travis-ci.com/github/haproxy/haproxy/jobs/298267505 > > > > > > > > I'll have a look > > > > > > It's complaining about this: > > > > > > error: unknown warning option '-Wno-free-nonheap-object'; did you > mean > > > '-Wno-sequence-point'? [-Werror,-Wunknown-warning-option] > > > > > > > https://bugs.chromium.org/p/boringssl/issues/detail?id=323 > > Great, thank you. > > > > Thus it's pretty clear that boringssl uses hard-coded gcc options and > > > is not even meant to be built with clang. We should probably roll back > > > to gcc for this one. I can do it if you want. > > > > > > > we use clang because of its address sanitizer. I found gcc asan more > noisy > > and less usable. > > > > > > anyway, we can switch back to clang-7 or gcc, until boringssl will fix > that. > > OK, I'll check which entry it is and revert the relevant part. > > Willy > From 5d5891166389dc03ab4fb63ca9edaa35feca8fcc Mon Sep 17 00:00:00 2001 From: Ilya Shipitsin Date: Mon, 16 Mar 2020 12:49:34 +0500 Subject: [PATCH] CI: switch BoringSSL back to clang-7 it turned out that BoringSSL is not prepared for clang-9 https://bugs.chromium.org/p/boringssl/issues/detail?id=323 until that issue is resolved, let us roll back to clang-7 --- .travis.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.travis.yml b/.travis.yml index 96f16ed42..05f4a3f1e 100644 --- a/.travis.yml +++ b/.travis.yml @@ -81,7 +81,7 @@ matrix: - os: linux if: type == cron compiler: clang -env: TARGET=linux-glibc BORINGSSL=yes CC=clang-9 +env: TARGET=linux-glibc BORINGSSL=yes CC=clang - os: linux if: type != cron compiler: clang -- 2.24.1
Re: [PATCH] switch to clang-9 in Linux/travis-ci builds
On Mon, Mar 16, 2020 at 11:52:27AM +0500, ??? wrote: > ??, 16 ???. 2020 ?. ? 11:35, Willy Tarreau : > > > On Sun, Mar 15, 2020 at 10:54:56PM +0500, ??? wrote: > > > ??, 14 ???. 2020 ?. ? 14:23, Willy Tarreau : > > > > > > > Hi Ilya, > > > > > > > > On Fri, Jan 24, 2020 at 11:46:45AM +0500, ??? wrote: > > > > > Hello, > > > > > > > > > > let us use clang-9 instead of default clang-7 for linux builds. > > > > > > > > It seems I missed this one. Now applied carefully, we'll see. If it > > > > causes new failures, we'll adjust accordingly. > > > > > > > > > > BoringSSL is not happy > > > https://travis-ci.com/github/haproxy/haproxy/jobs/298267505 > > > > > > I'll have a look > > > > It's complaining about this: > > > > error: unknown warning option '-Wno-free-nonheap-object'; did you mean > > '-Wno-sequence-point'? [-Werror,-Wunknown-warning-option] > > > > https://bugs.chromium.org/p/boringssl/issues/detail?id=323 Great, thank you. > > Thus it's pretty clear that boringssl uses hard-coded gcc options and > > is not even meant to be built with clang. We should probably roll back > > to gcc for this one. I can do it if you want. > > > > we use clang because of its address sanitizer. I found gcc asan more noisy > and less usable. > > > anyway, we can switch back to clang-7 or gcc, until boringssl will fix that. OK, I'll check which entry it is and revert the relevant part. Willy
Re: [PATCH] switch to clang-9 in Linux/travis-ci builds
пн, 16 мар. 2020 г. в 11:35, Willy Tarreau : > On Sun, Mar 15, 2020 at 10:54:56PM +0500, ??? wrote: > > ??, 14 ???. 2020 ?. ? 14:23, Willy Tarreau : > > > > > Hi Ilya, > > > > > > On Fri, Jan 24, 2020 at 11:46:45AM +0500, ??? wrote: > > > > Hello, > > > > > > > > let us use clang-9 instead of default clang-7 for linux builds. > > > > > > It seems I missed this one. Now applied carefully, we'll see. If it > > > causes new failures, we'll adjust accordingly. > > > > > > > BoringSSL is not happy > > https://travis-ci.com/github/haproxy/haproxy/jobs/298267505 > > > > I'll have a look > > It's complaining about this: > > error: unknown warning option '-Wno-free-nonheap-object'; did you mean > '-Wno-sequence-point'? [-Werror,-Wunknown-warning-option] > https://bugs.chromium.org/p/boringssl/issues/detail?id=323 > > Thus it's pretty clear that boringssl uses hard-coded gcc options and > is not even meant to be built with clang. We should probably roll back > to gcc for this one. I can do it if you want. > we use clang because of its address sanitizer. I found gcc asan more noisy and less usable. anyway, we can switch back to clang-7 or gcc, until boringssl will fix that. > > Willy >
Re: [PATCH] switch to clang-9 in Linux/travis-ci builds
On Sun, Mar 15, 2020 at 10:54:56PM +0500, ??? wrote: > ??, 14 ???. 2020 ?. ? 14:23, Willy Tarreau : > > > Hi Ilya, > > > > On Fri, Jan 24, 2020 at 11:46:45AM +0500, ??? wrote: > > > Hello, > > > > > > let us use clang-9 instead of default clang-7 for linux builds. > > > > It seems I missed this one. Now applied carefully, we'll see. If it > > causes new failures, we'll adjust accordingly. > > > > BoringSSL is not happy > https://travis-ci.com/github/haproxy/haproxy/jobs/298267505 > > I'll have a look It's complaining about this: error: unknown warning option '-Wno-free-nonheap-object'; did you mean '-Wno-sequence-point'? [-Werror,-Wunknown-warning-option] Thus it's pretty clear that boringssl uses hard-coded gcc options and is not even meant to be built with clang. We should probably roll back to gcc for this one. I can do it if you want. Willy
Re: [PATCH] switch to clang-9 in Linux/travis-ci builds
сб, 14 мар. 2020 г. в 14:23, Willy Tarreau : > Hi Ilya, > > On Fri, Jan 24, 2020 at 11:46:45AM +0500, ??? wrote: > > Hello, > > > > let us use clang-9 instead of default clang-7 for linux builds. > > It seems I missed this one. Now applied carefully, we'll see. If it > causes new failures, we'll adjust accordingly. > BoringSSL is not happy https://travis-ci.com/github/haproxy/haproxy/jobs/298267505 I'll have a look > > Willy >
Re: [PATCH] switch to clang-9 in Linux/travis-ci builds
Hi, On Sat, Mar 14, 2020 at 11:26 AM Willy Tarreau wrote: > Hi Ilya, > > On Fri, Jan 24, 2020 at 11:46:45AM +0500, ??? wrote: > > Hello, > > > > let us use clang-9 instead of default clang-7 for linux builds. > > It seems I missed this one. Now applied carefully, we'll see. If it > causes new failures, we'll adjust accordingly. > All looks good here on aarch64 with this change! Martin > > Willy > >
Re: [PATCH] switch to clang-9 in Linux/travis-ci builds
Hi Ilya, On Fri, Jan 24, 2020 at 11:46:45AM +0500, ??? wrote: > Hello, > > let us use clang-9 instead of default clang-7 for linux builds. It seems I missed this one. Now applied carefully, we'll see. If it causes new failures, we'll adjust accordingly. Willy
