Re: Segfault on 2.1.3
❦ 16 mars 2020 16:02 -06, Sean Reifschneider: > I reverted back to haproxy 2.0.13 from the PPA last Wednesday and have > verified that we get no segfaults on that. If there's anything else I can > provide for you, let me know. Otherwise I'm just gonna close this ticket > in our bugtracker. :-) Sorry, can't help you more. Maybe wait for the next release. It will get -dbgsym and it should provide more info on why you get the problem. -- Don't go around saying the world owes you a living. The world owes you nothing. It was here first. -- Mark Twain
Re: Segfault on 2.1.3
I reverted back to haproxy 2.0.13 from the PPA last Wednesday and have verified that we get no segfaults on that. If there's anything else I can provide for you, let me know. Otherwise I'm just gonna close this ticket in our bugtracker. :-) Sean On Fri, Mar 6, 2020 at 10:53 AM Sean Reifschneider wrote: > Here's what the stack traces look like, they all seem to be showing > "pattern_exec_match" and "epool_wait": > >PID: 14348 (haproxy) >UID: 0 (root) >GID: 0 (root) > Signal: 11 (SEGV) > Timestamp: Thu 2020-03-05 19:59:05 MST (14h ago) > Command Line: /usr/sbin/haproxy -Ws -f /etc/haproxy/haproxy.cfg -p > /run/haproxy.pid -S /run/haproxy-master.sock > Executable: /usr/sbin/haproxy > Control Group: /system.slice/haproxy.service > Unit: haproxy.service > Slice: system.slice >Boot ID: 847e3549533c4b9b970c6ec86776621d > Machine ID: 90c4e8de95634bd898f918ea24b07374 > Hostname: fw1 >Storage: > /var/lib/systemd/coredump/core.haproxy.0.847e3549533c4b9b970c6ec86776621d.14348.158346354500.lz4 >Message: Process 14348 (haproxy) of user 0 dumped core. > > Stack trace of thread 14349: > #0 0x564a9deaed08 pattern_exec_match (haproxy) > #1 0x564a9dee8eda acl_exec_cond (haproxy) > #2 0x564a9ded9848 tcp_exec_l4_rules (haproxy) > #3 0x564a9decfe24 session_accept_fd (haproxy) > #4 0x564a9debab44 n/a (haproxy) > #5 0x564a9dedc88e process_runnable_tasks (haproxy) > #6 0x564a9de87dd2 n/a (haproxy) > #7 0x7f0f0de6a6db start_thread (libpthread.so.0) > #8 0x7f0f0c8de88f __clone (libc.so.6) > > Stack trace of thread 14348: > #0 0x7f0f0c8debb7 epoll_wait (libc.so.6) > #1 0x564a9dda7cef n/a (haproxy) > #2 0x564a9de87dbf n/a (haproxy) > #3 0x564a9dda5a4e main (haproxy) > #4 0x7f0f0c7deb97 __libc_start_main (libc.so.6) > #5 0x564a9dda672a _start (haproxy) > > I have a bunch of ACLs to select the backend based on the host header, > like: > > acl sitedown_stg_acl hdr(host) -m reg -i ^sitedown.example.com > use_backend sitedown_stg if sitedown_stg_acl > > I'm not seeing anything particularly weird about those, the most > complicated is probably: > > acl aerial_acl hdr(host) -m reg -i ^aerial[1-4].(dev|stg).example.com > use_backend aerial if aerial_acl > > Thoughts? > > On Wed, Mar 4, 2020 at 1:56 PM Vincent Bernat wrote: > >> ❦ 4 mars 2020 13:19 -07, Sean Reifschneider : >> >> > I've upgraded back to 2.1, and installed the systemd-coredump, I'll >> update >> > when I have additional information. I wasn't able to find a -dbgsym >> > package, I even looked in the debian pool directory for the PPA. We're >> > talking like a haproxy-dbgsym package, right? Or am I missing >> > something? >> >> Sorry, I forgot to enable this option for 2.1 PPA. You should still be >> able to get tracebacks without the dbgsym package (with "coredumpctl >> info XXX"). >> -- >> Indent to show the logical structure of a program. >> - The Elements of Programming Style (Kernighan & Plauger) >> >
HAProxy & TheVPNShop.com - IPV6 Leak Test
Hi, My name is Stefan and I represent TheVPNShop.com who specialise in VPN comparison and reviews. We are hoping to change the way people shop and buy VPNs in a market that is currently only suited to the review sites who get paid to list VPNs in a certain order. Anyway, we are writing an article on iPV6 leak testing and when researching this on your site I noticed that the link on your homepage ( http://ipv6.haproxy.org/) is broken. Just wanted to let you know about that and if it would be possible to share our site with your users in some way? Let me know if this is possible. Stay Healthy Stefan
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] BUG/MEDIUM: spoe: dup agent's engine_id string from trash.area
Le 13/03/2020 à 07:54, Kevin Zhu a écrit : Hi The agent's engine_id forgot to dup from trash, all engine_ids point to the same address "", the engine_id changed at run time and will double-free when release agents and trash. Kevin Thanks, now applied ! -- Christopher Faulet
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
