https://github.com/ElektraInitiative/libelektra/issues/3140과 관련이

valgrind 및 ASAN 테스트에서 이와 같은 것이 실패 할 것 같지는 않습니다. 나는 C에서 유사한 벤치 마크를 실행 해 왔고 동일한 것을 관찰 할 수 없었다. mmap을 사용해도 비슷한 것을 볼 수 없습니다. 나는 그것을 배제하지 않습니다.

바인딩이 어딘가에 누출되지 않는 것이 확실합니까?

예, 확실합니다. 런타임 중에 go 애플리케이션의 메모리 사용량을 검사 할 수 있습니다. 이러한 통계에는 C 코드에 의한 할당이 포함되어 있지 않으며 애플리케이션 / 테스트의 총 메모리 사용량에 가깝지 않습니다. 대량의 메모리가 C에 할당됩니다.

내 의심은 ref 카운터가 != 0 이어야하지만 0 이므로 키가 해제되지 않는다는 것입니다.

즉, 바인딩은이 memleak을 트리거하는 방식으로 C API를 호출합니다. 불행히도 나는 이동을 모르기 때문에 왜 이런 일이 발생하는지 모르겠습니다.

누출을 유발하는 작은 C 예제를 추출 할 수 있습니까? 저는 benchmarks/kdb.c 에서 매우 유사한 작업을 수행하고 거기에 누출이 없으므로 누출을 유발하기 위해 벤치 마크가 수행하는 작업을 정확히 수행해야합니다.

문제를 신고 해 주셔서 감사합니다!

나는 여기서 @mpranj에 전적으로 동의합니다. 우리는 문제를 최소한의 것으로 줄여야합니다. 여러 언어가 관련되어있어서 아무것도 찾기가 어렵습니다.

go 바인딩에서 발행 된 호출 순서를 재현하는 C 프로그램을 작성할 수 있습니까? 일단 우리는 테스트 케이스를 위해 C 프로그램을 최소화 할 수 있습니다.

Btw. 위의 명령을 실행하려고하면 아주 일찍 실패했습니다. # 3159

내일까지 C로 재현 해 볼게요

이 문제를 여기에서 성공적으로 재현했습니다. benchmarks/memoryleak.c 벤치 마크를 실행하고 키 세트를 가져 오는 동안 메모리가 증가하는지 확인하고 해제 할 때 감소 하지 않는지 확인합니다.

DB에 눈에 띄는 양의 키를 추가하는 것을 잊지 마십시오. .. 저는 10 만 개의 키로 테스트했습니다.

예제를 만들어 주셔서 감사합니다! 내가 살펴볼 게.

언뜻보기에 정확히 하나의 직접 누출이 있으며 parentKey를 해제해야합니다.
https://github.com/raphi011/libelektra/blob/afcbcf5c8138be8de6ba9b1a9e559bc673ff887f/benchmarks/memoryleak.c#L22

이 작은 누출은 아마도 당신이 관찰 한 이유가 아닐 것입니다.

사이드 참고로 다음의 mmap 캐시를 사용하여, 나는 캐시하지 않고보다 더 적은 메모리 사용량을 확인할 수 있습니다. 아마 나는 이것을 내 논문에 추가해야 할 것입니다 : smile :. (캐시 : ~ 200M vs. 캐시 없음 : ~ 600M)

dlopen() / dlclose() 를 통해 메모리를 "누수"하는 것 같습니다. 다음은 kdb 하지만 kdb-static 사용하지 않으면 관찰 할 수 있습니다 (발췌).

valgrind --leak-check=full --show-leak-kinds=all ./bin/kdb ls user
[...]
==48451== 1,192 bytes in 1 blocks are still reachable in loss record 6 of 6
==48451==    at 0x483AB1A: calloc (vg_replace_malloc.c:762)
==48451==    by 0x400BB11: _dl_new_object (in /usr/lib64/ld-2.30.so)
==48451==    by 0x400642F: _dl_map_object_from_fd (in /usr/lib64/ld-2.30.so)
==48451==    by 0x4009315: _dl_map_object (in /usr/lib64/ld-2.30.so)
==48451==    by 0x400DB24: openaux (in /usr/lib64/ld-2.30.so)
==48451==    by 0x4DFE8C8: _dl_catch_exception (in /usr/lib64/libc-2.30.so)
==48451==    by 0x400DF6A: _dl_map_object_deps (in /usr/lib64/ld-2.30.so)
==48451==    by 0x4013AC3: dl_open_worker (in /usr/lib64/ld-2.30.so)
==48451==    by 0x4DFE8C8: _dl_catch_exception (in /usr/lib64/libc-2.30.so)
==48451==    by 0x401363D: _dl_open (in /usr/lib64/ld-2.30.so)
==48451==    by 0x496139B: dlopen_doit (in /usr/lib64/libdl-2.30.so)
==48451==    by 0x4DFE8C8: _dl_catch_exception (in /usr/lib64/libc-2.30.so)
[...]

귀하의 예제는 많은 핸들을 더 많이 열므로 다음과 같이 보입니다.

==48735== 72,704 bytes in 1 blocks are still reachable in loss record 8 of 8
==48735==    at 0x483880B: malloc (vg_replace_malloc.c:309)
==48735==    by 0x4F860A9: ??? (in /usr/lib64/libstdc++.so.6.0.27)
==48735==    by 0x400FD59: call_init.part.0 (in /usr/lib64/ld-2.30.so)
==48735==    by 0x400FE60: _dl_init (in /usr/lib64/ld-2.30.so)
==48735==    by 0x4013DBD: dl_open_worker (in /usr/lib64/ld-2.30.so)
==48735==    by 0x4A088C8: _dl_catch_exception (in /usr/lib64/libc-2.30.so)
==48735==    by 0x401363D: _dl_open (in /usr/lib64/ld-2.30.so)
==48735==    by 0x48C739B: dlopen_doit (in /usr/lib64/libdl-2.30.so)
==48735==    by 0x4A088C8: _dl_catch_exception (in /usr/lib64/libc-2.30.so)
==48735==    by 0x4A08962: _dl_catch_error (in /usr/lib64/libc-2.30.so)
==48735==    by 0x48C7B08: _dlerror_run (in /usr/lib64/libdl-2.30.so)
==48735==    by 0x48C7429: dlopen@@GLIBC_2.2.5 (in /usr/lib64/libdl-2.30.so)

이 예에서는 많은 KDB 핸들을 열어이 효과가 추가되어 상당한 메모리 소비가 발생합니다. 핸들을 하나만 열면 더 작아야합니다. @ raphi011 벤치 마크에 kdb-static 를 사용할 수 있는지 모르겠습니다. 벤치 마크를 elektra-static 라이브러리에 연결할 때 더 이상 동일한 것을 관찰 할 수 없습니다.

==54836== HEAP SUMMARY:
==54836==     in use at exit: 0 bytes in 0 blocks
==54836==   total heap usage: 6,456,631 allocs, 6,456,631 frees, 272,753,180 bytes allocated
==54836== 
==54836== All heap blocks were freed -- no leaks are possible
==54836== 
==54836== For lists of detected and suppressed errors, rerun with: -s
==54836== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

현재 dlopen() 문제에 대해 무엇을 할 수 있는지 잘 모르겠습니다.

이것은 새로운 elektrad 서버의 단순화 된 시뮬레이션입니다. 동시에 시스템을 구성하는 여러 사용자를 지원하기를 원하기 때문에 다중 핸들 (충돌 처리 등)을 지원해야합니다.

나는 여전히 이것이 문제의 근원이 아니라고 생각합니다. 문제는 키 / 키 세트가 해제되지 않는다는 것입니다. 상위 키를 훨씬 적은 키가있는 "system" 변경하면 메모리 소비가 훨씬 낮다는 것을 알 수 있습니다.

@ markus2330 어떻게 생각하세요?

편집 : 이것을 잊으십시오.

나는 우리가 거기에서 메모리를 누출하고 있다고 생각하지 않습니다.
https://gist.github.com/mpranj/bbdf00af308ed3f5b3f0f35bc832756f~~

위 요점의 코드를 사용하여 HTOP 및 메모리 사용량으로 설명하는 것과 동일한 것을 관찰 할 수 있습니다.

그래서 당신은 elektra의 메모리 소비가 결코 줄어들지 않는 것이 절대적으로 정상이라고 말하고 있습니까?

그래서 당신은 elektra의 메모리 소비가 결코 줄어들지 않는 것이 절대적으로 정상이라고 말하고 있습니까?

나는 그렇게 말하는 것이 아닙니다. 나는 elektra에 관계없이 똑같이 관찰했다는 것을 말한다. 방금 내 관찰이 valgrind로 실행할 때만 사실이라는 것을 알았으므로 valgrind는 다른 이유로 끝까지 free () ing되지 않을 수 있습니다.

https://stackoverflow.com/questions/40917024/memory-leak-after-using-calloc-and-free

포인터를 해제하기 전에 포인터를 변경했기 때문인 것 같습니다.

포인터를 해제하기 전에 포인터를 변경했기 때문인 것 같습니다.

나는 그렇게하지 않고 valgrind는 요점의 코드에 대한 누출을 보여주지 않습니다. 그러나 예제를 잊으십시오. valgrind 내부에서 실행될 때 즉시 해제되지 않기 때문에 관련성이 없습니다. 그렇지 않으면 메모리가 거의 즉시 해제됩니다.

더 관련성있는 점 : KDB를 전혀 사용하지 않는 benchmark_createkeys 를 사용하여 신고 내용을 관찰했습니다. 리소스도 즉시 free () d가 아니지만 valgrind는 누수가 전혀 없음을 보여줍니다. 나는 당황합니다.

@ markus2330 어떻게 생각하세요?

KeySet만으로는 확실히 누수가 없어야합니다. (KDB에서는 플러그인이 누출되는 다른 라이브러리를로드 할 수 있으므로 모든 것을 완전히 제어 할 수 없습니다.)

@ raphi011 PR을 만들거나 문제를 재현하는 최소한의 예를

https://github.com/raphi011/libelektra/tree/memoryleak 여기 있습니다. 키 참조 > 0 인해 ksDel 해제되지 않은 키 수를 인쇄하여 이전 예제를 확장했습니다.

valgrind 없이 벤치 마크를 실행하면 키가 해제되지 않았 음을 알 수 있습니다.

이 저장소를 컴파일 할 수 없습니다. 오류가 발생합니다.

CMake Error: Error processing file: /home/markus/Projekte/Elektra/repos/libelektra/scripts/cmake/ElektraManpage.cmake
make[2]: *** [src/bindings/intercept/env/CMakeFiles/man-kdb-elektrify-getenv.dir/build.make:61: ../doc/man/man1/kdb-elektrify-getenv.1] Fehler 1
make[1]: *** [CMakeFiles/Makefile2:17236: src/bindings/intercept/env/CMakeFiles/man-kdb-elektrify-getenv.dir/all] Fehler 2

메인 마스터로 리베이스 할 수 있습니까?

그리고 PR을 해주시면 변경 사항을 확인하는 것이 훨씬 쉽습니다.

valgrind없이 벤치 마크를 실행하면 키가 해제되지 않았 음을 알 수 있습니다.

여기에 실행 결과를 복사 할 수 있습니까?

KDB를 전혀 사용하지 않는 bench_createkeys를 사용하여보고하는 내용을 관찰했습니다. 리소스도 즉시 free () d가 아니지만 valgrind는 누수가 전혀 없음을 보여줍니다. 나는 당황합니다.

KeySet 만 있으면 이해하기 훨씬 쉽기 때문에 먼저이 추적을 따라야한다고 생각합니다.

valgrind에 잘못된 억제를 추가했을까요?

참고로 mmap 캐시를 사용하면 캐시가 없을 때보 다 메모리 사용량이 적다는 것을 알 수 있습니다. 논문의 미소에 이것을 추가해야 할 수도 있습니다. (캐시 : ~ 200M vs. 캐시 없음 : ~ 600M)

이것은 확실히 좋은 소식입니다.

여기 있습니다 : https://github.com/ElektraInitiative/libelektra/pull/3172

valgrind에 잘못된 억제를 추가했을까요?

Valgrind는 테스트를 실행할 때 억제를 사용하지 않는다고보고했지만 귀하의 마일리지는 다릅니다.

벤치 마크에서 문제를 발견 한 것 같습니다. 나에게 문제는 각 키에 대한 메타 키 세트를 열심히 할당하는 것입니다. 내 브랜치에서 더티 테스트를 한 후 열망하는 메타 KeySet 할당을 제거하면 ksDel () 후에 메모리 소비가 빠르게 감소합니다. 내가 말하는 코드를 변경하기 때문에 # 3142에 의해 수정되었을 수 있습니다.

자, 그럼 # 3142가 문제를 해결하는지 봅시다!

@ raphi011 문제가 # 3081 이전에도 발생 했습니까?

3142가 이제 병합되었습니다. @ raphi011 문제가 계속 발생하는지 확인할 수 있습니까?

불행히도 그렇습니다

나에게는 적어도 몇 가지 문제를 해결 / 완화하는 것 같습니다. 이제 2GB 메모리를 사용하는 수백만 개의 키로 벤치 마크를 실행할 수 있지만 이전에는 동일한 벤치 마크에 대해 20GB 이상의 메모리를 사용하기 때문에 충돌이 발생했습니다.

나에게는 적어도 몇 가지 문제를 해결 / 완화하는 것 같습니다. 이제 2GB 메모리를 사용하는 수백만 개의 키로 벤치 마크를 실행할 수 있지만 이전에는 동일한 벤치 마크에 대해 20GB 이상의 메모리를 사용하기 때문에 충돌이 발생했습니다.

아직 이전 버전과 비교하지는 않았지만 이전보다 적은 메모리를 사용한다고 확신합니다. 오늘 확인하겠습니다!

그래도 메모리는 여전히 해제되지 않습니다.

free 마다 malloc_trim(0) 로 전화해야합니다 (읽기 : ksDel ). 이렇게하면 glibc가 즉시 메모리를 OS에 반환합니다. 이것은 여러분이보고있는 "이상한 행동"을 고칠 것입니다. 오, 재미있게 읽고 glibc를 파헤 치세요 :-)

추가 테스트 / 수정을 위해 # 3183을 만들었습니다.

하나의 memleak을 찾았습니다 (kdbGet에서 리턴 키가 해제되지 않았습니다).

그러나 "ksClose가 532 개의 키를 해제하지 않음"의 증가는 아마도 parentKey에 수집 된 경고 일뿐입니다. 예를 들어 100 개처럼 NUM_RUNS 개를 더 올리면 경고 횟수가 100 개로 제한되어있어 어느 시점에서 정체됩니다. "ksClose는 901 개의 키를 해제하지 않았습니다." 핸들 당 parentKey가 있으면이 문제를 해결할 수 있습니다.

# 3183에 의해 폐쇄