2011-12-18 1 views
3

최근에 libmysqlclient을 사용하는 C 프로그램을 작성하기 시작했습니다. valgrind으로 코드를 검사 할 때 메모리 누수가보고되었습니다. ...MySQL C API 메모리 누출?

==25614== LEAK SUMMARY: 
==25614== definitely lost: 0 bytes in 0 blocks 
==25614== indirectly lost: 0 bytes in 0 blocks 
==25614==  possibly lost: 0 bytes in 0 blocks 
==25614== still reachable: 288 bytes in 3 blocks 
==25614==   suppressed: 0 bytes in 0 blocks 

를 MySQL의 API 참조, mysql_close()에 따르면

닫기 횟수 : 나에게 말한다

#include <mysql.h> 

int main(void) 
{ 
    MYSQL* mysql = mysql_init(0); 

    mysql_close(mysql); 

    return 0; 
} 

valgrind와 결과 프로그램을 확인 : 다음 최소한의 코드는 동작을 재현 이전에 열린 연결. mysql_close()는 핸들이 mysql_init() 또는 mysql_connect()에 의해 자동으로 할당 된 경우 mysql이 가리키는 연결 핸들을 할당 해제한다.

그러나 valgrind은 해제되지 않은 메모리를보고합니다. 여기 뭐가 잘못 됐니?

+0

아마도 한번 초기화 된 내부 버퍼일까요? –

+0

나는 이것이 로컬 타임과 친구들을 사용하여 누출을 탐지하는 valgrind와 관련이 있다고 생각한다. – Ulterior

+0

Michael : 네 말이 맞아, 내 대답을 보라. – Philip

답변

6

문서를 파헤 쳐서이 문제를 해결하는 mysql_library_end() 함수를 찾았습니다.

MySQL의 API 참조에서 인용 :

이 기능은 MySQL의 라이브러리를 확정. 라이브러리 사용을 마쳤 으면 (예 : 서버 연결을 끊은 후에) 호출해야합니다. 개인 노트에

, 나는 오히려 성가신 libmysqlclient 세력의 사용자가 자신의 정리 함수를 호출하는 것을 찾을 수 있습니다. IMO의 경우 더 좋은 해결책은 연결 수가 0으로 떨어지면 자동으로 mysql_library_end()으로 전화하는 것입니다.

+4

6 분 차이를 만들 수 있습니다 – Ulterior

+0

Ulterior : 문구가 나에게 더 오래 걸렸습니다. – Philip

+0

나는 오늘도 똑같은 것을 발견했기 때문에 library_end o.O를 수동으로 호출해야한다는 것을 약간 바보로 느꼈다. –