Hi Frank,

On Fri, Apr 06, 2018 at 10:53:36AM +0000, Frank Schreuder wrote:
> We tested haproxy 1.8.6 with compression enabled today, within the first few 
> hours it already went wrong:
> [ALERT] 095/120526 (12989) : Current worker 5241 exited with code 134

OK thanks, and sorry for that.

> Our other balancer running haproxy 1.8.5 with compression disabled is still
> running fine after 2 days with the same workload.
> So there seems to be a locking issue when compression is enabled.

Well, an issue with compression, but I'm really not seeing what makes
you speak about locking since :
  - you don't seem to have threads enabled
  - locking issues generally cause deadlocks, not aborts

The other problem is that we noticed already that there are very few
abort() calls in haproxy and none of them in this area. So it's very
possible that it comes from another layer detecting an issue provoked
by compression. Typically the libc's malloc/free can stop the program
using abort() if they detect a corruption.

It would really help to know where this abort() happens, at least to
get a backtrace.

By the way, area you using zlib or slz ? zlib uses a tricky allocator.
I checked it again yesterday and it was made thread safe. But we couldn't
rule out an issue there. slz doesn't need memory however. If you're on
zlib, switching to slz could also indicate if the problem is related to
these memory allocations or not.


Reply via email to