I added "-O1" to travis builds. Can we apply it until a better solution will be found ?
пт, 12 июн. 2020 г. в 21:40, Илья Шипицин <chipits...@gmail.com>: > > > пт, 12 июн. 2020 г. в 21:09, Willy Tarreau <w...@1wt.eu>: > >> On Fri, Jun 12, 2020 at 08:57:44PM +0500, ???? ??????? wrote: >> > ??, 12 ???. 2020 ?. ? 20:46, Willy Tarreau <w...@1wt.eu>: >> > >> > > 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 <chipits...@gmail.com> 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
