2014-12-22 2 views
9

코어 파일 분석에서 메모리 누수를 분석하고 싶습니다.코어 덤프에서 메모리 누수를 분석하는 방법

메모리 누수를 주입하고 gcore 명령으로 코어 파일을 생성하는 샘플 코드를 작성했습니다.

#include <stdlib.h> 
#include <unistd.h> 
void fun() 
{ 
    int *ptr = new int(1234); 
} 
int main() 
{ 
    int i=0; 
    while(i++<2500) 
    { 
    fun(); 
} 
sleep(360); 
return 0; 
} 

프로세스 ID

[email protected]:~$ ps -aef |grep over 
ajay  8735 6016 0 12:57 pts/2 00:00:00 ./over 
ayadav 8739 4659 0 12:57 pts/10 00:00:00 grep over 

생성 된 코어를 찾기

[email protected]:~$ sudo gcore 8735 
[sudo] password for ayadav: 
0x00007fbb7dda99a0 in __nanosleep_nocancel() at ../sysdeps/unix/syscall-template.S:81 
81  ../sysdeps/unix/syscall-template.S: No such file or directory. 
Saved corefile core.8735 

나는 다음과 같이 코어 파일에서 일반적인 패턴을 발견했다 (에 제안을 유래 다른 스레드 Is there a way to locate which part of the process used the most of the memory, only looking at a generated core file?)

[email protected]:~$ hexdump core.6015 | awk '{printf "%s%s%s%s\n%s%s%s%s\n", $5,$4,$3,$2,$9,$8,$7,$6}' | sort | uniq -c | sort -nr | head 
6913 0000000000000000 
2503 0000002100000000 
2501 000004d200000000 
786 0000000000007ffc 
464 
125 1ccbc4d000007ffc 
92 1ca7ead000000000 
91 0000000200007ffc 
89 0000000100007ffc 
80 0000000100000000 

이 아래 주소는 반복 패턴

0003560 0000 0000 0021 0000 0000 0000 04d2 0000 
0003570 0000 0000 0000 0000 0000 0000 0000 0000 
0003580 0000 0000 0021 0000 0000 0000 04d2 0000 
0003590 0000 0000 0000 0000 0000 0000 0000 0000 
00035a0 0000 0000 0021 0000 0000 0000 04d2 0000 
00035b0 0000 0000 0000 0000 0000 0000 0000 0000 
00035c0 0000 0000 0021 0000 0000 0000 04d2 0000 
00035d0 0000 0000 0000 0000 0000 0000 0000 0000 
00035e0 0000 0000 0021 0000 0000 0000 04d2 0000 
00035f0 0000 0000 0000 0000 0000 0000 0000 0000 
0003600 0000 0000 0021 0000 0000 0000 04d2 0000 
0003610 0000 0000 0000 0000 0000 0000 0000 0000 
0003620 0000 0000 0021 0000 0000 0000 04d2 0000 
0003630 0000 0000 0000 0000 0000 0000 0000 0000 
0003640 0000 0000 0021 0000 0000 0000 04d2 0000 

다음 하나 개

2503 0000002100000000 
2501 000004d200000000 

코어 파일을 한 것으로 의심되는하지만 내가 GDB 정보 주소 또는 X 같은 명령에서 액세스 할 수 있습니다 얼마나 많은 생각이 없습니다. 아무도 내가 이진 형식에서 기호 정보를 어떻게 변환 할 수 있는지 말할 수 있습니까?

+0

[코어 덤프 파일 분석] (http://stackoverflow.com/questions/5115613/core-dump-file-analysis) – gj13

+0

가능한 중복 [프로그램의 코어 덤프 파일을 분석하는 방법은?] (http://stackoverflow.com/questions/8305866/how-to-analyze-a-programs-core-dump-file) – skaffman

+0

중복되지 않습니다 –

답변

7

1 - 코어 덤프로 메모리 누수를 평가할 수 있습니다.

class Base 
{ 
public: 
    virtual void fun(){} 
    virtual void xyz(){} 
    virtual void lmv(){} 
    virtual void abc(){} 
}; 

class Derived: public Base 
{ 
public: 
    void fun(){} 
    void xyz(){} 
    void lmv(){} 
    void abc(){} 
}; 

void fun() 
{ 
    Base *obj = new Derived(); 
} 
int main() 
{ 
    for(int i = 0; i < 2500;i++) 
    { 
     fun(); 
    } 
    sleep(3600); 
    return 0; 
} 

2 - gcore 명령 명령

3 코어를 생성 - 코어 파일에서 반복되는 패턴을 검색 나는 ++ 예 C 샘플을 촬영했다.

[email protected]:~$ hexdump core.10639 | awk '{printf "%s%s%s%s\n%s%s%s%s\n", $5,$4,$3,$2,$9,$8,$7,$6}' | sort | uniq -c | sort -nr | head 
    6685 0000000000000000 
    2502 0000002100000000 
    2500 004008d000000000 
    726 0000000000007eff 
    502 
    125 2e4314d000007eff 
    93 006010d000000000 
    81 0000000100007eff 
    80 0000000100000000 
    73 0000000000000001 

0000002100000000004008d000000000 패턴

4

을 반복 - 각 QWORD가 무엇을 함께 확인?

(gdb) info symbol ... 
(gdb) x ... 

예 :

(gdb) info symbol 0x4008d000 
No symbol matches 0x4008d000. 
(gdb) info symbol 0x4008d0 
vtable for Derived + 16 in section .rodata of /home/ayadav/virtual 

5 - 아마 가장 많이 VTABLE 메모리 누출 즉 파생 VTABLE 관련한다.

참고 : 코어 덤프 분석은 메모리 누수를 찾는 것이 가장 좋습니다. 메모리 누출은 valgrind와 같은 다른 정적 및 동적 도구로 찾을 수 있습니다.

+2

유닉스 생각이 마음에 들지만 핵심 파일에서 어떤 종류의 할당이 현재 활성화되어 있는지를 알아낼 수 있어야한다고 ... [핵심 분석기] (http : //core-analyzer.sourceforge.net/)이 나타났습니다. – nonsensickle

2

프로세스가 메모리 누수를 일으키는 지 또는 코어 덤프를 직접보고 있지 않는지 식별하는 방법이 있다고 생각하지 않습니다. 사실, 메모리 누출이라고하는 것은 없기 때문에 코드를 작성하려는 프로그래머의 의도를 알지 못하면서 그 주석을 작성할 수 없습니다. 그런 말로 코어 덤프의 크기를보고 아이디어를 얻을 수 있습니다. 여러 개의 덤프를 생성 할 수 있습니다. 첫 번째 실행 후 하나는 장기 실행 후 하나, 크기가 큰 차이가 나는 경우 뭔가 잘못 될 수 있음을 알 수 있습니다. 그러나 다시 메모리는 생산적인 목적으로 사용될 수 있습니다.

메모리 누수의 실제 분석과 추적을 위해, memtrack, valgrind 등과 같은 도구를 사용하여 malloc을 통해 래퍼를 추가하고 각 alloc 및 free에 대한 추가 정보를 자유롭게 제공해야합니다.

업데이트 : 귀하의 모든 라인은 16 바이트와 두 줄의 반복이다 :

당신은 내가 볼 수있는 여기, 육각 분석을 위해 찾고있다. 32 바이트의 청크입니다. 0x4D2는 십진수로 1234입니다. 따라서 귀하의 데이터가 있습니다. 하나의 alloc 청크가 32 바이트 일 수 있습니다. 확인하고 모든 '새()'후 16 진수로 주소를 인쇄하고 32 바이트 간격을 관찰하는 경우 다음 그것을 설명하는 비교하십시오.

+1

Hi Joe, http://stackoverflow.com/questions/8710404/is-there-a-way-to-locate-which-part-of-the-process-used-the-most-of -기억. 코어 덤프에서 메모리 누출을 찾을 수 있습니다. 내가 Valgrind 같은 도구를 사용할 수 있지만 필자는 핵심 파일에서 분석하고 싶습니다. 귀하의 요청에 따라 –

+0

답변이 업데이트되었습니다. 그러나 이것이 메모리 누수를 디버그하는 올바른 방법이라고 생각하지 않습니다. – joe

+1

안녕하세요, Joe, 정말 고마워요. 예 alloc 청크는 32 바이트 갭입니다. 0x12c4010 0x12c4030 0x12c4050 0x12c4070 0x12c4090 0x12c40b0 0x12c40d0 0x12c40f0 0x12c4110 0x12c4130 0x12c4150 0x12c4170 하지만 난 –

관련 문제