Hello Tim,

Just to update you, I have tried the patch, and while I didnt see any new
occurences of the underflow, HAProxy started to crash constantly...

Jan 07 10:32:37 afrodite haproxy[14364]: [ALERT] 006/103237 (14364) :
Current worker #1 (14366) exited with code 139 (Segmentation fault)
Jan 07 10:32:37 afrodite haproxy[14364]: [ALERT] 006/103237 (14364) :
exit-on-failure: killing every workers with SIGTERM
Jan 07 10:32:37 afrodite haproxy[14364]: [WARNING] 006/103237 (14364) : All
workers exited. Exiting... (139)

I am not sure if the segfaults are related to the patch - Continuing
investigation...

BR.,
Emerson


Em qui, 3 de jan de 2019 às 21:48, Emerson Gomes <emerson.go...@gmail.com>
escreveu:

> Hello Tim,
>
> Thanks a lot for the patch. I will try it out and let you know the results.
>
> BR.,
> Emerson
>
> Em qui, 3 de jan de 2019 às 21:18, Tim Düsterhus <t...@bastelstu.be>
> escreveu:
>
>> Emerson,
>>
>> Am 03.01.19 um 21:58 schrieb Emerson Gomes:
>> > However, the underflow scenario only seem to be possible if the peers
>> are
>> > sending relative values, rather than absolute ones.
>>
>> I don't believe so. My hypothetical timeline was created with absolute
>> values in mind.
>>
>> > Apparently both cases (absolut and offset values) exist.
>> > I am looking at src/peers.c to understand how the peer protocol works
>> and
>> > maybe create the patch you proposed (do not decrement counter if
>> already 0).
>>
>> I attached a patch which I believe fixes the issue (checking for 0 when
>> decrementing, not touching the peers).
>>
>> > However it seems that a real fix would require some big changes on the
>> > protocol itself.
>>
>> Yes I agree.
>>
>> > One potencial implementation I could imagine, would be to, rather than
>> > broadcasting absolute values or offsets, each neighbor peer could report
>> > the amount of connection it has locally only, and it would be up to the
>> > local node to resolve the actual value by adding up the different values
>> > received from all neighbors.
>>
>> Yes, that probably would be the most reliable implementation. It takes
>> up more memory and processing power, though.
>>
>> > Not even sure if my understading is correct, but it's task currently
>> out of
>> > my reach.
>> > Should I do a bug report somewhere? :)
>> >
>>
>> I suspect that the developers will notice this thread. A proper issue
>> tracker is a wish of mine as well
>> (https://www.mail-archive.com/haproxy@formilux.org/msg32239.html).
>>
>> Best regards
>> Tim Düsterhus
>>
>

Reply via email to