Hi Aleksey, On Fri, Jun 22, 2018 at 07:08:22AM +0300, Aleksey Gordeev wrote: > Once a week it restarts with sigfault > > Jun 21 17:04:29 v54 kernel: haproxy[303]: segfault at 2670ff8 ip > 00007f0c375824e1 sp 00007ffd2f8d7528 error 4 in libc-2.17.so > [7f0c37427000+1c3000] > Jun 21 17:04:29 v541 haproxy: [ALERT] 169/070052 (302) : Current worker 303 > exited with code 139 > Jun 21 17:04:29 v54haproxy: [ALERT] 169/070052 (302) : exit-on-failure: > killing every workers with SIGTERM > Jun 21 17:04:29 v54 haproxy: [WARNING] 169/070052 (302) : All workers > exited. Exiting... (139) > > > It's difficult to create dump because it's rare case.We use 5 instances of > haproxy. Only one fails. The main difference is that it has huge json > payloads. Other hosts serves web sites. This one - api.
Thanks for reporting this. Based on some other reports of the same libc offset found in various other daemon crashes on the net, it looks like it would be in strncpy(). Fortunately we have very few such calls in haproxy. Most of them are at boot time in the config parser, so since it dies at run time they don't count. A few are in Lua but you don't use it. One is in stats but I suspect you'd notice if it crashes at the moment you access the stats page. And one is in the http "set-status" action which you don't use either. Thus, unless it's in fact the stats page, it's likely that this offset in your libc is different from the one found on others and that it's not in strncpy() at all. Could you please indicate on what distro this is ? It could help if you could enable core dumps for next time it happens. I'm a bit worried thinking that uploading JSON could cause a crash since we don't process data but just forward them. Maybe the API client uploads using chunked encoding (which is less common) and we could have an issue there, but libc is not used in this area :-/ So at this moment I don't have any clue. Regards, Willy
