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 <[email protected]> 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 <[email protected]> > 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/[email protected]/msg32239.html). >> >> Best regards >> Tim Düsterhus >> >
