>> >>>> There are very few abort() calls in the code :
>> >>>> - some in the thread debugging code to detect recursive locks ;
>> >>>> - one in the cache applet which triggers on an impossible case very
>> >>>> likely resulting from cache corruption (hence a bug)
>> >>>> - a few inside the Lua library
>> >>>> - a few in the HPACK decompressor, detecting a few possible bugs there
>> After playing around with some config changes we managed to not have haproxy
>> throw the "worker <pid> exited with code 134" error for at least a day. Which
>> is a long time as before we had this error at least 5 times a day...
>> The line we removed from our config to get this result was:
>> compression algo gzip
> Hmmm interesting.
>> Could it be a locking issue in the compression code? I'm going to run a few
>> more days without compression enabled, but for now this looks promising!
> In fact, the locking is totally disabled when not using compression, so
> it cannot be an option. Also, most of the recently fixed bugs may only
> be triggered with H2 or threads, none of which you're using. I rechecked
> the compression code to try to spot anything obvious, but nothing popped
> out :-/
> All I can strongly recommend if you retry with compression enabled is to
> do it with latest 1.8 release. I'm currently checking that I didn't miss
> anything to issue 1.8.6 hopefully today. If it still dies, this will at
> least rule out the possible side effects of a few of the bugs we've fixed
> since, all of which were really tricky.
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
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.