메모리 누수를 해결하는 것이 얼마나 중요합니까?

19

Valgring은 일부 GTK + 프로그램이 메모리 누수를 발견했습니다. 누출을 해결하는 것이 얼마나 중요합니까? 내 말은, 종종 그 프로그램들은 아주 잘 작동하지만, 다른 한편으로, 누수 코드의 일부를 다른 프로그램에 복사하고 싶을 때 결코 확신 할 수 없습니다. 그리고 GTK + 프로그램의 아이디어가 빨리 작동하여 누출이 있는지 확실하지 않습니다.

따라서 오픈 소스 프로그램에서 메모리 누수가 발견되면 문제를 해결해야합니까 아니면 효율성 문제와 같은 문제가 있습니까? 그래서 프로그래머에게는 원래의 작은 누수 코드를 작성하는 것이 좋습니까?

c memory

— 자코 세 팔라
소스

17

메모리 누수는 항상 바람직하지 않습니다. 호스트 프로그램을 포함하여 프로그램이 종료 될 때까지 전체 시스템이 사용할 수없는 자원을 나타냅니다.

— recursion.ninja

메모리 누수를 추적하는 데 필요한 도구 / 라이브러리가 충분합니다. 귀하의 API 사용이 잘못되었을 수 있으므로 노력할 가치가 있습니다.

— Joop Eggen

1

참고로-valgrind는 훌륭하지만 잘못된 긍정을보고 할 수 있습니다 (GObject에서 보았습니다).

— Maciej Piechotka

계산은 처리 및 메모리에 따라 다릅니다. 전자는 코드이고, 후자는 코드가 실행되는 공간입니다. 자신의 방을 휴지통으로 넘기지 않는다고 믿을 수 없다면 어떻게 유용한 무언가를 사용할 수 있습니까?

— imallett

1

"코드를 유지하는 사람은 당신이 사는 곳을 알고있는 폭력적인 정신병자 인 것처럼 항상 코드를 작성하십시오."

— Jesse C. Slicer

6

메모리 누수를 해결하는 것이 얼마나 중요한지는 문제의 심각성에 따라 달라져야 할 중요한 사항에 달려 있습니다. 내 경험에 따르면 작은 메모리 누수는 대부분의 응용 프로그램에서 다소 양 성적입니다. 데스크탑 앱 세션의 수명은 일반적으로 작은 메모리 누수로 인한 성능 저하를 볼 수있을만큼 길지 않습니다.

연중 무휴로 운영되는 서버를 작성하는 경우 시간이 지남에 따라 작은 메모리 누수가 증가하여 주요 문제가 될 수 있습니다. 그러나 많은 회사에서 매일 또는 매주 서버가 다시 시작되도록 예약합니다. 메모리 누수를 찾는 노력은 종종 얻을 수있는 것에 비해 과도하므로, 정기적으로 서버를 다시 시작하고 더 중요한 것으로 이동하는 것이 더 쉽습니다.

— 모헤어
소스

2

나는 매주 서버를 다시 시작한 회사에서 일한 적이 없었습니다. 나는 누출을 고치기위한 비용이 그것을 고치기 위해 높을 수도 있지만이 사고 방식을 갖는 것은 좋지 않다는 것에 동의한다

— Rémi

@ Rémi 전부는 아니지만 대부분의 MMO 게임 서버는 대개 주 단위로 사용합니다.

— Sjoerd

35

짧은 실행 프로그램의 경우 메모리 누수가 중요하지 않습니다. OS는 종료시 모든 것을 회수하지만 다른 리소스가 해제되지 않을 수 있습니다.

그러나 짧은 실행은 상대적이며, 누출은 몇 시간 내에 통제 불능 상태가되거나 몇 주 동안 누적 될 수 있습니다.

내 조언은 추적 프로그램에 버그가 제기 된 수정 프로그램을 제출하는 것입니다.

누출 유형도 중요합니다. 누수 할당은 의도적으로 정리를 위해 OS에 의존하는 일회성 할당 일 수 있습니다. 이것들은 valgrind에 거짓 긍정을 줄 것입니다.

— 래칫 괴물
소스

4

나는 대부분 동의합니다. 그러나 메모리 누수의 중요성을 강조하는 것이 좋습니다. 메모리 누수는 가볍게 발생하지 않으며 응용 프로그램의 흥미로운 "기능"을 유발할 수 있습니다.

— Vladimir Kocjancic

@VladimirKocjancic : 1 "기능"에 대한

— 에밀리오 Garavaglia

1

컴퓨터가 수백만 번의 처리를 수백만 번 매우 빠르게 수행 할 수 있다고 지적하고 싶습니다. 잊지 마세요. 그래서 당신이 그것을 고려한다면, 나는 이것이 실제로 프로그램에 달려 있기 때문에이 대답에 동의합니다. 사람의 개입없이 실행되도록 내장 된 시스템의 경우 메모리 누수가 심각합니다. "grep"구현의 경우 아마 신경 쓰지 않을 것입니다.

— Dunk

2

@ 덩크 : 그것은 달려있다 : grep매우 큰 파일을 통해 프로그램이 각 입력 라인에 대해 몇 바이트를 누출하면 메모리가 부족 할 수 있습니다.

— Giorgio

0

이 한 가지 주제에 대한 저의 독단적 인 견해로는, 적어도 광범위하게 적용되는 것을 목표로하는 어떤 도서관에서도 물리적 누출에 대한 변명이 없습니다. 그래서 GTK + 개발자가 스스로 고칠 때까지 버그를 해결하려고합니다.

라이브러리가 atexit적어도 언로드 될 때 할당 한 메모리를 해제하기 위해 콜백을 등록하기에 충분합니다 . 조그마한 배가 많은 비용을 피하고 싶다면 처음부터 그렇게해서는 안됩니다.

아주 작은 메모리 덩어리를 한 번에 할당하려는 게으른 프로그램조차도 종료시 모든 메모리를 제거하는 간단한 순차적 할당자를 사용할 수 있습니다. 할당자가 정렬을 다루고 싶지 않다면 풀링하는 모든 청크를 최대 정렬 경계까지 채울 수 있습니다. 작은 메모리 청크를 모두 개별적으로 해제하지 않음으로써 더 빠른 종료 시간으로 이익을 얻을 수 있다면 마찬가지로 메모리를 똑바로 순차적으로 풀링하는 순차 할당자를 사용함으로써 사소한 노력 대신에 대칭 적으로 많은 이익을 얻을 수 있습니다. 보다 빠른 할당malloc더 캐시에 친숙한 메모리 패턴으로, 라이브러리가 완료 될 때 할당 자에 의해 풀링 된 모든 연속 메모리 블록이 해제되도록합니다. 라이브러리는 다음을 수행하는 모든 자신의 교체이다 malloc그들이 귀찮게하지 않은 전화 free처럼 뭔가 seq_malloc및 통화 seq_purge에서 atexit언로드 될 때 할당 된 모든 메모리를 해제하는 콜백을.

그렇지 않으면이 불쾌한 라이브러리가 메모리 누수 감지 도구에서 메시지를 정리하여 이제 필터링해야합니다. 더 나쁜 것은, 체계적으로 걸러 내지 않으면 자신의 애플리케이션에서 누수를 가릴 수 있고 동료가이를 간과하는 습관을 길러서 누출 탐지 툴의 유용성을 떨어 뜨릴 수 있습니다. 새는 코드 푸시. 그것은 거칠고 추악하며 무엇보다도 위의 솔루션을 사용하는 것이 얼마나 사소한 일인지에 대해 의도적으로 설득력있는 주장을 찾지 못했습니다.

논리적 누수 (가비지 수집조차도 보호 할 수없는 더 복잡한 종류)는 더 복잡한 문제이며, 할당 된 모든 메모리를 제거하는 한 수명이 짧은 프로그램에 논리적 누수가있을 수 있습니다. 논리적 유출을 피하기 위해 리소스 관리에 대해 많은 생각이 필요하기 때문에 종료됩니다 (물론 GC가있는 언어의 경우 더 그렇습니다). 그러나 나는 게으른 상황에서도 피해야 할 사소한 물리적 누출을 피할 합리적인 변명을 찾지 못했습니다.

어쨌든, 나는 최소한 valgrind에서 누출을 걸러내어 적어도 팀이 당신의 능력을 엉망으로 만들지 않도록합니다.

1

누출이 "보트 코딩"과 관련이 있는지 궁금합니다.

0

FWIW, 사용자가 작업중 인 응용 프로그램에서 누수를보고하면 문제를 해결하는 경향이 있습니다 (특히 버그 보고서에 수정 코드가 포함 된 경우). 즉, 누출이 적고 다른 문제가 더 긴급한 경우 (즉, 자주 발생하는 충돌 버그) 즉시 발생하지 않을 수 있습니다. 그러나 나는 그것을 고맙게 생각하고 결국 고치기 위해 노력할 것입니다. 반드시 그들에게 알려 주어야합니다. 그들은 그것을 평가하고 그것을 고치려고 노력할 것입니다 (대부분의 가능성이 있습니다).

— 사용자 1118321
소스