98
Tất cả các chức năng được đề cập trong khối này là các hàm thư viện. Làm thế nào tôi có thể khắc phục sự rò rỉ bộ nhớ này?Rò rỉ có thể tiếp cận được phát hiện bởi Valgrind
Được liệt kê trong danh mục "Vẫn có thể truy cập". (Có 4 hơn, đó là rất giống nhau, nhưng kích thước khác nhau)
630 bytes in 1 blocks are still reachable in loss record 5 of 5
at 0x4004F1B: calloc (vg_replace_malloc.c:418)
by 0x931CD2: _dl_new_object (dl-object.c:52)
by 0x92DD36: _dl_map_object_from_fd (dl-load.c:972)
by 0x92EFB6: _dl_map_object (dl-load.c:2251)
by 0x939F1B: dl_open_worker (dl-open.c:255)
by 0x935965: _dl_catch_error (dl-error.c:178)
by 0x9399C5: _dl_open (dl-open.c:584)
by 0xA64E31: do_dlopen (dl-libc.c:86)
by 0x935965: _dl_catch_error (dl-error.c:178)
by 0xA64FF4: __libc_dlopen_mode (dl-libc.c:47)
by 0xAE6086: pthread_cancel_init (unwind-forcedunwind.c:53)
by 0xAE61FC: _Unwind_ForcedUnwind (unwind-forcedunwind.c:126)
Catch: Khi tôi chạy chương trình của tôi, nó đã không có rò rỉ bộ nhớ, nhưng nó có một dòng bổ sung trong đầu ra Valgrind, mà đã không được trình bày trước:
Syms thải sơn 0x5296fa0-0x52af438 trong /lib/libgcc_s-4.4.4-20100630.so.1 do munmap()
Nếu rò rỉ không thể được sửa chữa, có thể ai đó atleast giải thích tại sao munmap() dòng nguyên nhân Valgrind để báo cáo 0 "vẫn có thể truy cập" rò rỉ?
Edit:
Đây là một mẫu thử nghiệm tối thiểu:
#include <stdio.h>
#include <stdlib.h>
#include <pthread.h>
void *runner(void *param) {
/* some operations ... */
pthread_exit(NULL);
}
int n;
int main(void) {
int i;
pthread_t *threadIdArray;
n=10; /* for example */
threadIdArray = malloc((n+n-1)*sizeof(pthread_t));
for(i=0;i<(n+n-1);i++) {
if(pthread_create(&threadIdArray[i],NULL,runner,NULL) != 0) {
printf("Couldn't create thread %d\n",i);
exit(1);
}
}
for(i=0;i<(n+n-1);i++) {
pthread_join(threadIdArray[i],NULL);
}
free(threadIdArray);
return(0);
}
Run with:
valgrind -v --leak-check=full --show-reachable=yes ./a.out
bạn có thể phỏng đoán những gì munmap() đang làm mà làm cho "vẫn có thể truy cập" khối biến mất? –
@crypto: Có thể là 'munmap' được gọi là kết quả của việc dỡ bỏ một đối tượng được chia sẻ. Và tất cả các tài nguyên được sử dụng bởi các đối tượng chia sẻ có thể được giải phóng trước khi nó được dỡ xuống. Điều này có thể giải thích lý do tại sao "vẫn có thể tiếp cận" được giải phóng trong trường hợp 'munmap'. Tôi chỉ suy đoán ở đây, mặc dù.Không có đủ thông tin ở đây để nói chắc chắn. –
Một trường hợp bộ nhớ "vẫn có thể truy cập" có thể được coi là rò rỉ bộ nhớ: giả sử bạn có bảng băm nơi bạn thêm con trỏ vào bộ nhớ được cấp phát là giá trị. Nếu bạn tiếp tục chèn các mục nhập mới trên bảng, nhưng sẽ không xóa và giải phóng những mục bạn không cần nữa, nó có thể phát triển vô thời hạn, rò rỉ sự kiện bộ nhớ heap nếu bộ nhớ đó là "vẫn có thể truy cập". Đây là trường hợp rò rỉ bộ nhớ bạn có thể có trong Java hoặc các ngôn ngữ thu thập rác khác. – lvella