* 질문 등록 시 다음의 내용을 꼭 기입하여 주세요.
| Linux 64bit | |
| CUBRID 9.3 (9.3.6.0002) (64bit release build for linux_gnu) | |
| 9.3.6.007 (64bit) | |
| c++ |
* CUBRID 응용 오류, SQL 오류 또는 SQL 튜닝 관련된 문의는 반드시 다음의 내용을 추가해 주세요. 비밀글이나 비밀 댓글도 가능합니다.
* 저희가 상황을 이해하고, 재현이 가능해야 알 수 있는 문제들이 많습니다. 가능한 정보/정황들을 부탁합니다.
CCI 드라이버 사용 할 때 http://www.cubrid.org/manual/ko/9.2.0/api/cci.html?highlight=cci_prepare#c.cci_prepare 의 예제 1 의 실행파일이 있다면 Valgrind 로 실행 할 경우 메모리 누수 발생 cci_close_req_handle ( ) 호출 시 net_buf_realloc (cci_net_buf.c:288) 소스 부분의 malloc 된 메모리 가 delete( ) 되는지 체크 해 주시면 될 것 같습니다. |
재현 가능한 Source와 SQL |
| 관련 테이블(인덱스, 키정보 포함) 정보 | CUBRID 홈 디렉토리 아래 log 디렉토리 압축 |
-------------- 아래에 질문 사항을 기입해 주세요. ------------------------------------------------------------------------
Valgrind 로 메모리 누수 부분을 돌려보니 cci_prepare() 함수 호출 후
cci_close_req_handle( ); 로 close 해주었는데도 net_buf_realloc (cci_net_buf.c:288) 소스 부분의 malloc 된 메모리가 해지 안되는 현상이 있는듯 합니다.
따로 해지할 수 있는 방법이 있을까요?
아래는 Valgrind 수행 결과입니다.
==13137== Address 0xb7fda61 is 65 bytes inside a block of size 1,024 alloc'd
==13137== at 0x4C29BE3: malloc (vg_replace_malloc.c:299)
==13137== by 0x5072C0B: net_buf_realloc (cci_net_buf.c:288)
==13137== by 0x5072C0B: cnet_buf_cp_str (cci_net_buf.c:117)
==13137== by 0x5070E29: qe_prepare (cci_query_execute.c:448)
==13137== by 0x5068508: cci_prepare (cas_cci.c:950)
답변 부탁 드리겠습니다. 감사합니다.
안녕하세요. 큐브리드를 이용해주셔서 감사합니다.
cci_disconnect(con, &cci_error);를 호출하시면 malloc된 메모리가 해제 될 것입니다.
감사합니다.
아래는 cci_close_req_handle()이후 cci_disconnect()까지 수행한 결과입니다.
[bagus@newTest2 RunCcode]$ valgrind --leak-check=yes ./simple
==27387== Memcheck, a memory error detector
==27387== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==27387== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==27387== Command: ./simple
==27387==
1 |test |test |
2 |[ttt]test |[ttt]test |
3 |[[ttt]]test |[[ttt]]test |
==27387==
==27387== HEAP SUMMARY:
==27387== in use at exit: 0 bytes in 0 blocks
==27387== total heap usage: 92 allocs, 92 frees, 31,715 bytes allocated
==27387==
==27387== All heap blocks were freed -- no leaks are possible