Hi guys,

On Sun, Jan 05, 2014 at 09:36:03PM +0100, Lukas Tribus wrote:
> Hi,
> 
> 
> > Disabling epoll doesn't fix it... drat... Tested it with ss-20140104.
> > Could it be that it's a more subtle bug somewhere else?
> 
> If disabling epoll doesn't workaround that problem then another patch must
> be the reason for this.
> 
> 
> > But, Yes, that is correct. 20131115 works and 2013116 doesn't.
> 
> There is only one single other patch between those 2 snapshots:
> Commit 38d5892634 ("OPTIM/MINOR: mark the source address as already known
> on accept()"). Could it be that you made a "off-by-one" error when
> troubleshooting (sorry for suggesting this - but its the only thing I can
> think of really)?
> 
> Could you retry with current code and only revert that particular patch?
> 
> If you use git, then you just:
> git revert 38d5892634
> 
> Otherwise you reverse apply this patch again:
> patch -p1 -R <0104-OPTIM-MINOR-mark-the-source-address-as-alre-1.5-dev19.diff
> 
> 
> 0104-OPTIM-MINOR-mark-the-source-address-as-alre-1.5-dev19.diff is in
> haproxy-1.5-dev19-patches-20131116.tar.gz [1].
> 
> 
> If this doesn't help, we probably need to troubleshoot this from another
> angle, by comparing debug logs of working and non-working situation, but
> knowing what exact patch introduced the problem is a very valuable
> information.
> 
> 
> PS: git is a real lifesaver when you do this kind of troubleshootings.
> Reverting patches, "git bisect" to find the patch to blame, you don't need
> to fiddle with diff files, etc.

I would go even further (using git). What I understand here is that the issue
was introduced after the epoll optimization and is hidden by this one. So I'd
rather start by reverting that patch and then looking up for another faulty
patch after those :

  1) create a new branch called test1 starting at the first faulty commit :

     git checkout -b test1 2f877304

  2) apply the revert patch first :

     git cherry-pick 3ef5af3d

  3) OK now both the faulty patch and the revert are merged, it makes sense
     to confirm that the bug is still not there.

  4) now rebase all further patches on top of these ones : Git will re-apply
     all other patches after the ones above. You will thus have a working
     version to start from :

     git checkout -b test2 master
     git rebase test1

  5) ensure that branch test2 is wrong by doing a test

  6) bisect the code from test1 which was verified to be good at 3) and test2
     which was verified to be bad at 5) :

     git bisect start test2 test1

It will offer you another patch which introduced the regression hidden by the
one above.

Thanks!
Willy


Reply via email to