Thank you; I had missed the context from 1.9.6. I've updated my test machine and will report back on Monday (or earlier, if it runs into trouble)
-- Richard Russo [email protected] On Fri, Apr 12, 2019, at 4:17 AM, Olivier Houchard wrote: > Hi, > > On Fri, Apr 12, 2019 at 08:37:10AM +0200, Maciej Zdeb wrote: > > Hi Richard, > > > > Those patches from Olivier (in streams) are related to my report from > > thread "[1.9.6] One of haproxy processes using 100% CPU", but as it turned > > out it wasn't a single bug and issue is not entirely fixed yet. > > > > Currently I'm testing some additional patches from Olivier which hopefully > > fix the issue definitely. > > > > Indeed, the rmoeval of SI_FL_ERR in si_update_both() was bogus, and covered > misuses of it. > With the great help of Maciej, we investigated this, and I just pushed what > we fixed so far. Richard, I'd be really interested in knowing if you still > have issues with the latest master. > > Thanks ! > > Olivier > > > pt., 12 kwi 2019 o 00:01 Richard Russo <[email protected]> napisał(a): > > > > > It seems that after applying 39cc020af, if a stream gets the SI_FL_ERR > > > flag, process_stream can keep going back to redo around stream.c:line > > > 2503: > > > > > > if (si_f->state == SI_ST_DIS || si_f->state != si_f_prev_state || > > > si_b->state == SI_ST_DIS || si_b->state != si_b_prev_state || > > > ((si_f->flags | si_b->flags) & SI_FL_ERR) || > > > (((req->flags ^ rqf_last) | (res->flags ^ rpf_last)) & > > > CF_MASK_ANALYSER)) > > > goto redo; > > > > > > Now that si_update_both no longer clears the SI_FL_ERR flag, and nothing > > > else does, the goto will get called forever. I don't understand this > > > section enough to try to reproduce this, but I found several processes > > > stuck here on a machine testing from yesterday's HEAD. > > > > > > Richard > > > > > > -- > > > Richard Russo > > > [email protected] > > > > > > >
