On 2017/1/17 17:02, Willy Tarreau wrote:
> Hi Patrick,
>
> On Tue, Jan 17, 2017 at 02:33:44AM +0000, Patrick Hemmer wrote:
>> So on one of my local development machines haproxy started pegging the
>> CPU at 100%
>> `strace -T` on the process just shows:
>>
>> ...
>> epoll_wait(0, {}, 200, 0) = 0 <0.000003>
>> epoll_wait(0, {}, 200, 0) = 0 <0.000003>
>> epoll_wait(0, {}, 200, 0) = 0 <0.000003>
>> epoll_wait(0, {}, 200, 0) = 0 <0.000003>
>> epoll_wait(0, {}, 200, 0) = 0 <0.000003>
>> epoll_wait(0, {}, 200, 0) = 0 <0.000003>
>> ...
> Hmm not good.
>
>> Opening it up with gdb, the backtrace shows:
>>
>> (gdb) bt
>> #0 0x00007f4d18ba82a3 in __epoll_wait_nocancel () from /lib64/libc.so.6
>> #1 0x00007f4d1a570ebc in _do_poll (p=<optimized out>, exp=-1440976915)
>> at src/ev_epoll.c:125
>> #2 0x00007f4d1a4d3098 in run_poll_loop () at src/haproxy.c:1737
>> #3 0x00007f4d1a4cf2c0 in main (argc=<optimized out>, argv=<optimized
>> out>) at src/haproxy.c:2097
> Ok so an event is not being processed correctly.
>
>> This is haproxy 1.7.0 on CentOS/7
> Ah, that could be a clue. We've had 2 or 3 very ugly bugs in 1.7.0
> and 1.7.1. One of them is responsible for the few outages on haproxy.org
> (last one happened today, I left it running to get the core to confirm).
> One of them is an issue with the condition to wake up an applet when it
> failed to get a buffer first and it could be what you're seeing. The
> other ones could possibly cause some memory corruption resulting in
> anything.
>
> Thus I'd strongly urge you to update this one to 1.7.2 (which I'm going
> to do on haproxy.org now that I could get a core). Continue to monitor
> it but I'd feel much safer after this update.
>
> Thanks for your report!
> Willy
>
So I just had this issue recur, this time on version 1.7.2.
-Patrick
