On Thu, Dec 7, 2017 at 4:36 AM, Olivier Houchard <ohouch...@haproxy.com> wrote: > Hi Christopher, > > On Wed, Dec 06, 2017 at 05:34:15PM -0800, Christopher Lane wrote: >> On Mon, Dec 4, 2017 at 11:56 AM, Christopher Lane >> <ch...@disputingtaste.com> wrote: >> > >> > >> > >> > On Mon, Dec 4, 2017 at 4:22 AM Lukas Tribus <lu...@ltri.eu> wrote: >> > >> >>Hello Christopher, >> > >> > >> >>2017-12-01 20:59 GMT+01:00 Christopher Lane <ch...@disputingtaste.com>: >> >>> >> >>> gist with backtrace, -vv output, and config file. Also strace. >> >>> >> >>> https://gist.github.com/jayalane/c6dbe7918aa9635b62c874d20f57dfec >> >>> >> >>> It does all the listens and then right after the first epoll is done it >> >>> has this segv. all the local variables are "optimized out" >> >>> >> >>> (We really want the hard-stop-after -- we get a leak of children with our >> >>> super frequent soft-reloads). >> > >> >>FYI, hard-stop-after has been backported to 1.7 stable and is in all >> >>rebuilds starting with 1.7.4: >> > >> >> https://www.mail-archive.com/haproxy@formilux.org/msg25494.html >> > >> > >> > >> >> Regards, >> >> Lukas >> > >> > Olivier: >> > >> > The patch worked beautifully to keep the 1.8.0 from crashing. >> > >> > Lukas: >> > >> > Thanks for the tip, we'll consider 1.7.9 then (settled on 1.8.0 by starting >> > out with reading the release notes for it; we are upgrading from 1.5.0). >> > >> > --Chris >> >> Unrelated to the prior contents of this thread, I found the root cause >> for our issue (child leak). >> >> The haproxy was being started from a Java process using Runtime.exec() >> and the PIDs were jammed into 1 cell of argv. It killed the first >> child but not the later ones, as atol("13233 13234 13235 13236") >> returns 13233. We have fixed the Java code. >> >> http://git.haproxy.org/?p=haproxy.git;a=blob;f=src/haproxy.c;h=eb5e65b40e7b8b2a4f8fb04b3552401e42fb0a89;hb=HEAD#l1421 >> >> I note that the -sf parsing code uses atol and has no error checking. >> Would the project be interested in a patch to use strtol with error >> checks? Could log a warning if unconsumed bytes in the arg (safer), >> or fail to start (unsafe). I'm sure I'm not the only one with this >> sort of bug, given how tricky shell escaping and so on is. > > Yes, replacing ato* with something more reasonnable would certainly be > appreciated :) > > Regards, > > Olivier
Didn't really see a place to put in tests for it, but did build git master and try it with various correct and incorrect args. Patch is under subject: [PATCH] CONTRIB: log: emit warning when -sf/-sd cannot parse argument Thanks, --Chris
