Re: [2.0.17] crash with coredump

Good day, I'd like to share with your my two cents regarding this topic: >> lrandom (PRNG for lua, we're using it for 2 or 3 years without any >> problems, and soon we will drop it from our build) > > Never heard of this last one, not that it would make it suspicious at > all, just that it

Re: [2.0.17] crash with coredump

Hi Kirill, Thanks for your hints and time! Unfortunately, I think lrandom is not the cause of crash. We're using lrandom with threads for couple of months on our other servers without any crash. I think lua in HAproxy is executed in a single thread so your analysis is correct but this assumption

Re: [2.0.17] crash with coredump

Hi Kirill, On Fri, Sep 25, 2020 at 12:34:16PM +0200, Kirill A. Korinsky wrote: > I've extracted a pice of code from lrandom and put it here: > https://gist.github.com/catap/bf862cc0d289083fc1ccd38c905e2416 > > > You can see that

Re: [2.0.17] crash with coredump

> Here I can suggest to implement Yarrow PRGN (that is very simple to > implement) with some lua-pure cryptographic hash function. We're using lrandom because of the algorithm Mersenne Twister and its well known weaknesses and strengths. > In fact I know it's possible to call haproxy's internal

Re: [2.0.17] crash with coredump

> On 25. Sep 2020, at 15:06, Willy Tarreau wrote: > > Till here your analysis is right but: > - the overflow would only be at most the number of extra threads running >init_genrand() concurrently, or more precisely the distance between >the most upfront to the latest thread, so in the

Re: [2.0.17] crash with coredump

> On 25. Sep 2020, at 15:26, Maciej Zdeb wrote: > > I was mailing outside the list with Willy and Christopher but it's worth > sharing that the problem occurs even with nbthread = 1. I've managed to > confirm it today. I'm curious is it crashed at the same place with the same value? -- wbr,

Re: [2.0.17] crash with coredump

Yes at the same place with same value: (gdb) bt full #0 0x559ce98b964b in h2s_notify_recv (h2s=0x559cef94e7e0) at src/mux_h2.c:783 sw = 0x pt., 25 wrz 2020 o 15:42 Kirill A. Korinsky napisał(a): > > On 25. Sep 2020, at 15:26, Maciej Zdeb wrote: > > > > I was mailing

Re: [2.0.17] crash with coredump

Very interesting. Anyway, I can see that this pice of code was refactored some time ago: https://github.com/haproxy/haproxy/commit/f96508aae6b49277dcf142caa35042678cf8e2ca Maybe it is worth to try 2.2 or 2.3

Re: source algorithm - question.

hi, thanks for answer, Not exactly, rather a mix of source and first. reason behind is that in case that we have free resources, different clients would get different machines, with "first" you will get first available slot - and reason behind is to scale down source works good until one client

Re: [2.0.17] crash with coredump

On Fri, Sep 25, 2020 at 03:26:05PM +0200, Maciej Zdeb wrote: > > Here I can suggest to implement Yarrow PRGN (that is very simple to > > implement) with some lua-pure cryptographic hash function. > > We're using lrandom because of the algorithm Mersenne Twister and its well > known weaknesses and

Re: source algorithm - question.

On Fri, Sep 25, 2020 at 03:57:58PM +0200, Lukasz Tasz wrote: > first is opposite to leastconn - first keep load at the beginning, > leastconn same everywhere. Indeed. > but why source is limiting balancing only to one machine? Because in almost every case people want to use it to maintain

Re: [2.0.17] crash with coredump

On Fri, Sep 25, 2020 at 03:26:47PM +0200, Kirill A. Korinsky wrote: > > On 25. Sep 2020, at 15:06, Willy Tarreau wrote: > > > > Till here your analysis is right but: > > - the overflow would only be at most the number of extra threads running > >init_genrand() concurrently, or more

Re: [PATCH] BUILD: trace: include tools.h

Hi Miroslav, On Thu, Sep 24, 2020 at 09:43:56AM +0200, Miroslav Zagorac wrote: > Hello, > > haproxy cannot be compiled on debian 9.13 if the TRACE option is used. Thanks, applied! Note below: > --- > src/calltrace.o: In function `make_line': > .../src/calltrace.c:204: undefined reference to

RE: Random with Two Choices Load Balancing Algorithm

Wondering if this was ever implemented? Norman Branitsky Senior Cloud Architect P: 416-916-1752 -Original Message- From: Willy Tarreau Sent: Saturday, December 15, 2018 11:09 AM To: Norman Branitsky Cc: haproxy@formilux.org Subject: Re: Random with Two Choices Load Balancing Algorithm

Re: Random with Two Choices Load Balancing Algorithm

Hi Norman, On Fri, Sep 25, 2020 at 03:58:54PM +, Branitsky, Norman wrote: > Wondering if this was ever implemented? Yes it was merged into 2.0, it's used by default when you select random since it's always slightly better than a naive random, and you can even configure it to set the number

Re: [PATCH] BUILD: trace: include tools.h

On 09/25/2020 05:59 PM, Willy Tarreau wrote: Git uses the "---" marker as an end of commit message, to put your comments to committers below. So when I applied your patch, it dropped this part. I've reintroduced it, but I thought you would like to know in order not to get caught by accident on

[ANNOUNCE] haproxy-2.3-dev5

Hi, HAProxy 2.3-dev5 was released on 2020/09/25. It added 104 new commits after version 2.3-dev4. Willy has finally finished the first part of the listeners rework and pushed a bunch of patches. First, the listener and bind_conf structures have been reorganized to better suite the new design.