[완료] send 하고 recv 가 안 되었을 때
글쓴이: jos77 / 작성시간: 토, 2008/10/25 - 7:47오후
안녕하세요 리눅스 C 초보자입니다.
서버 프로그램이 죽는데요. 엉뚱한 데에서 죽습니다.
loop ()
{
select()
recv ( request buffer);
buffer = 여럿 malloc(), free() 복잡한 연산();
send ( buffer) ;
}
이렇게 되어있는데요.
스트레스 테스트를 하려고 client 프로그램을 만들어서
loop (스트레스 수)
send (request buffer)
를 했더니
복잡한 연산 - free() 부분에서 2번째 loop 에서 바로 죽네요
client 프로그램을
loop (스트레스 수)
{
send (request buffer)
recv (buffer)
}
이렇게 하면 안 죽습니다. @_@
디버깅 도중에 SIGPIPE 가 한번 났었는데요. 그것도 한 번 나고는 지금은 안나네요.
도움 부탁드립니다. ㅠ.ㅠ
Forums:
너무 막연합니다.
답변이 없는 질문 글들은 보통 정확한 내용을 알 수 없는 막연한 질문인 경우가 많지요.
jos님의 질문도 저 내용만으로는 정확한 원인 파악이 매우 힘듭니다.
차라리 전체 source code를 올리시는게 나을 수 있을 것 같습니다.
일단 의심스러운 부분들을 지적하자면.
client가 loop를 돌면서 send만 할 때는 server가 죽어버리는데, client가 loop 안에서 send/receive를 모두 할 경우에는 잘 동작한다는 것인가요?
상식적으로 생각해 보면, server측이 receive이후 무언가 작업하고 그 결과를 다시 send하는 방식이므로, client쪽에서 부하를 줄 때에도 send한 이후 server쪽에서 보낸 결과를 받아가는 것이 정상일 듯 합니다. 따라서 위의 질문이 맞다면, client가 loop를 돌면서 단순히 내용을 보내기만 한다면 무언가 이상한게 아닌가 싶다는 것이지요. (일반적으로 저런 경우 server측에서는 send가 다 안 끝났으면 해당 fd에서 더이상 새로운 recv를 하지 않게 되어 client쪽에서도 send에서 blocking 상태에 빠지게 되는 것이 정상일 듯 싶습니다.)
뭐 그것들 외에도, select를 사용했다고 하지만 그 아래 루틴들을 봤을 땐 blocked i/o 를 사용한 패턴인듯 싶어 그쪽 부분도 조금 아리송하군요.
마지막으로.
free에서 죽었다면 대체로 세가지 경우가 있는데,
1. 이미 해당 memory가 free된 경우입니다. 즉 malloc받은 memory를 두번 free한 경우입니다.
2. 할당받은 크기 이상으로 사용하여 memory가 깨진 경우입니다. 즉 100byte를 할당받고 실제로는 110 byte를 사용했다거나 하면 malloc에서 사용하는 구조체가 깨져, 다른 곳에서 malloc을 하거나 free를 할 때 죽어버릴 수 있습니다.
3. 엉뚱한 memory를 free하려고 한 경우입니다. 여러 bug로 인해 pointer값이 깨져버렸는데, 그걸 모르고 이상한 값이 들어있는 pointer로 free를 하려 하면 죽어버릴 수 있습니다.
뭐 저 셋중에 어느 문제일지는...
ㅠ.ㅠ
SIGPIPE 랑 socket close 오류였네요 죄송합니다. 예전에 해결되었네요
-----
안녕하세요 소프트웨어 공학센터 장원석 책임입니다.
http://www.software.kr
댓글 달기