스택이 손상되는거 같습니다.
PVPGN에 접속자가 34000~35000명쯤 될때 서버가 멈춰서
gdb로 attach 한뒤 bt full 을 했더니
#6 0x0000000000470388 in file_get_line (fp=0x11834d8) at common/util.c:126
line = 0x1d095340 ""
len = 64
pos = 0
prev_char = 0
curr_char = 3
#7 0x0000000000410fe3 in message_send_file (dst=0x1a86fc00, fd=0x11834d8) at bnetd/message.c:1921
buff = 0x3
__FUNCTION__ = "message_send_file"
#8 0x000000000040cf6b in conn_set_channel (c=0x1a86fc00, channelname=0x5c4280 "/fbs/conf/motd/bnmotd.txt")
at bnetd/connection.c:185
---Type to continue, or q to quit---
acct_tag = 0x11834d8 ""
created = 0
channel = (t_channel *) 0x6ce900
oldchannel = (t_channel *) 0x0
acc = (t_account *) 0xb7bdb40
curr = (t_elem *) 0x0
clantag = 3
oldlist = (t_list *) 0x5c4280
destch = (t_channel *) 0x11834d8
__FUNCTION__ = "conn_set_channel"
#9 0x0000000000418cab in _client_joinchannel (c=0x1a86fc00, packet=0x1f4ab000) at bnetd/handle_bnet.c:3239
account = (t_account *) 0xb7bdb40
cname = 0x1f4ab018 "Brood War"
user_clan = (t_clan *) 0x3
clantag = 3
clienttag = 3
channel = (t_channel *) 0x3
__FUNCTION__ = "_client_joinchannel"
#10 0x0000000000411883 in handle (htable=0x1, type=3327, c=0x1a86fc00, packet=0x1f4ab000) at bnetd/handle_bnet.c:361
p = (const t_htable_row *) 0x482720
res = 3
#11 0x00000000004119aa in handle_bnet_packet (c=0x1a86fc00, packet=0x1f4ab000) at bnetd/handle_bnet.c:331
__FUNCTION__ = "handle_bnet_packet"
fread함수에서 블록킹되어있는데 fd가 제 생각엔 존재할리가 없는 fp입니다.
또,
#8 0x000000000040cf6b in conn_set_channel (c=0x1a86fc00, channelname=0x5c4280 "/fbs/conf/motd/bnmotd.txt")
at bnetd/connection.c:185
channelname이 "/fbs/conf/motd/bnmotd.txt" 일리가 없습니다. 분명히 아래 패킷 처리에서 cname = 0x1f4ab018 "Brood War" 이니까요..
#10 0x0000000000411883 in handle (htable=0x1, type=3327, c=0x1a86fc00, packet=0x1f4ab000) at bnetd/handle_bnet.c:361
또 htable이 0x1일리가 없습니다. bnetd/handle_bnet.c 의 331 line은 switch (handle(bnet_htable_log, packet_get_type(packet), c, packet)) { 인데 bnet_htable_log이라는 함수는 전역변수이기 때문입니다.
결정적으로 bnetd/connection.c:185 는 conn_set_channel 함수가 아닙니다.
제 생각으로는 서버 데몬이 돌다가 중간에서 스택이 꼬여서 이런 결과가 나온거같은데..
다들 디버깅은 어떻게 하시는지요..
제 생각엔 함수 실행중에 스택이 이상하게 변하면 프로그램의 실행을 중단하고 core 파일을 남기는 라이브러리나 프로그램이 있을거같은데..
플랫폼이나 상황에
플랫폼이나 상황에 따라 gdb가 잘못된 위치를 넘겨줄 수도 있습니다.
보통 메모리 침범이 가장 의심되는데 접속자 수가 그정도 증가할 때까지 문제가 안생기는 것이 더 이상하네요;;;
연속된 메모리 블럭에 대해 침범이 일어난 경우 glibc 레벨에서 캐치가 안될 때도 있습니다.
이런 경우 미친척하고 valgrind로 돌려보거나;; malloc 계열을 디버깅 가능한 라이브러리(dmalloc)로 대체하는 방법을 쓸 수 있습니다.
malloc를 하면 메모리를 할당할 때 메모리의 checksum을 달아뒀다가 메모리 변경시 이 checksum들을 체크해서 변조되었는지 확인하고 그런짓을 합니다.
pvpgn이 뭔지 방금 검색했는데 프리배넷 그런거군요;;
스택이 깨진건
스택이 깨진건 뭔가의 underflow 나 overflow 으로 인해 스택 메모리가 깨진 것 같은데요.
스택 깨졌을때 디버깅은 매우 힘들지요.
재현이 가능한 상황이면 윗분이 말씀한신 것 처럼 valgrind, dmalloc, efence 등으로 실험해 보시면 될 것 같네요.
그리고 접속자가 35000 근방에서 에러가 난다면, client 의 접속 요청에 대한 accept 가 실패하거나 외부로 접속을 맺는 connect 가 실패할 수 있는 수치에 근접한 것 같군요
(리눅스의 client 에게 할당하는 tcp port 범위 기본값이 30000~65000 까지 인가 그렇거든요)
댓글 달기