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] > > > >
