调用getaddrinfo导致程序僵死

jazy333

#0  0x0000003668ce6b5d in recvmsg () from /lib64/libc.so.6
#1  0x0000003668d0c7b5 in make_request () from /lib64/libc.so.6
#2  0x0000003668d0cbea in __check_pf () from /lib64/libc.so.6
#3  0x0000003668cd0107 in getaddrinfo () from /lib64/libc.so.6
#4  0x000000000046d2db in http_client::connect_timeout (this=0x314a940, host=0x5472a5f8 "10.134.58.92", port=0x85df8918 "20002", timeout=0x7f0158799f10) at http_client.cpp:392
#5  0x000000000046c047 in http_client::post (this=0x314a940, path="/invalid", data=
    "key=m%001%006%007%008%004%000%004%003%003%001%004%002%000%006%006%003%008%008%008%008%00.%001%00%2C%00m%001%006%007%008%004%000%004%003%003%001%004%002%000%006%006%003%008%008%008%008%00.%002%00") at http_client.cpp:194


程序死在getaddrinfo 调用里，看网上有人说是make_request在调用recvmsg时有bug，有人遇到过这种问题吗？怎么处理的？

linux_c_py_php

dns服务不稳定，超时了吧。

jazy333

有可能是dns超时引起的，但是也不应该是永远都不返回啊
另外我跟踪了下glibc的代码，发现好像是死在了获取netlink接口的地址信息时

Vsky_man

回复 3# jazy333


    请问下你是怎么跟踪glib代码的~？

jazy333

下载响应版本的glibc，然后根据堆栈查看各个函数

gaojl0728

回复 1# jazy333


    这个应该跟DNS关系不大，很可能是glibc的版本和内核版本 不匹配造成的

查了下glibc 2.18 的代码，make_request的时候glibc会发送一个netlink请求给内核， 然后等待内核返回netlink response，
看起来是内核没有回response, 所以glibc一直挂在recvmsg等待(默认是超时是无限大)，

查了下内核linux 2.6.18的内核代码， 内核会检查netlink 请求的标志位，只有带NLM_F_DUMP标志的请求内核才会回response，
新的内核linux 3.15并不检查这个标志, 总是回response

所以我感觉你这个问题的根源可能是glibc的版本和内核版本 不匹配造成的。
glibc 2.18的netlink请求并不带NLM_F_DUMP， 所以如果是glibc-2.18 + linux 2.6.18, glibc也是一样会hang住的。

可以查一下你的linux kernel版本和glib的版本， 看是不是有这个问题。

jazy333

内核： 2.6.32-220.17.1.el6.x86_64 #1 SMP Thu Apr 26 13:37:13 EDT 2012 x86_64 x86_64 x86_64 GNU/Linux
glibc:glibc-2.12-1.47.el6_2.12.i686
[@sjs_129_87 ~]# rpm -qi glibc
Name        : glibc                        Relocations: (not relocatable)
Version     : 2.12                              Vendor: Red Hat, Inc.
Release     : 1.47.el6_2.12                 Build Date: Fri 20 Apr 2012 12:04:23 AM CST

多谢分析

winsty

请问一下这个问题解决了吗？我最近也碰到这个问题了。回复 7# jazy333