Re: Fwd: [haproxy/haproxy] BUG/MAJOR: server: Segfault after parsing server state file. (0bedb8a)

[Tim Düsterhus]

Willy,(writing from my phone, blame it, if I mess up the quotes) Am 23.05.2018 11:20 vorm. schrieb Willy Tarreau :
Well, please post here instead, it's where people are present and

follow the activity. I'm adding Fred in CC since he's the one who fixed

the crash, and Baptiste as well since he's the state file designer.
Please note that the initial comment on GitHub is not written by me. I'm very well aware that the list is to be used.I'm just the messenger, I don't know the original author and I suspect that the original author will not read this mailing list thread, because GitHub does not give out their email address. Someone should probably comment on the GitHub commit, hinting to the mailing list. I can do so tomorrow when I'm back at my computer. Best regardsTim Düsterhus

Re: Fwd: [haproxy/haproxy] BUG/MAJOR: server: Segfault after parsing server state file. (0bedb8a)

[Willy Tarreau]

Hi Tim,

On Tue, May 22, 2018 at 09:52:16PM +0200, Tim Düsterhus wrote:
> Hi list
> 
> the following comment has been posted to GitHub on commit
> 0bedb8ac90ffdf1498a999c44d1c91556fb726ee
> 
> https://github.com/haproxy/haproxy/commit/0bedb8ac90ffdf1498a999c44d1c91556fb726ee#commitcomment-29087381

Well, please post here instead, it's where people are present and
follow the activity. I'm adding Fred in CC since he's the one who fixed
the crash, and Baptiste as well since he's the state file designer.

So it's about commit 0bedb8a ("BUG/MAJOR: server: Segfault after parsing
server state file.").

> @wtarreau This patch causes the state of the haproxy to be discarded by
> the haproxy unless the server id of the backend server is not fixed.
> Normally they are auto-generated and removing e.g. 1st server on the
> list of backends results in renumerating all server ids :(

So if I understand right, the problem is in fact that servers from the
state file which don't exist in the config file are reported as mismatches,
thus the code for the ID/name mismatch was modified instead of modifying
the special case. I don't know what could be done to detect such cases.
At the very least, given that the previous code used to crash in this
case, it means this condition differs in a detectable way (possibly that
a server lookup returns null or something like this).

I'll let Fred and Baptiste take a look.

Thanks,
Willy