On 06.01.2014 15:10, Willy Tarreau wrote:
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.
I will do the bisect as soon as I have time.
On a side note, today I had an issue with another loadbalancer running
ss-20140101 which showed almost the same behavior as the 'NTLM' bug I
was having. (hanging connection, or waiting a loooong time and the
giving a corrupt file) This bug only happened with certain downloads
(jpg's) with http compression enabled. If a browser requested the file
without the compression header everything was fine.
Downgrading to dev19 also fixed this issue. I don't know if this could
be related somehow.
Greets,
Sander
