2011-12-07 4 views
2

저는 ansi C로 컴파일하면서 64 비트 Linux centos 5.7에서 gcc4.4.4와 gdb를 사용하고 있습니다. 왜 코드가 아래의 PDF == NULL에 해당하는지 테스트하고 exit (2)를 호출하는지 잘 모르겠습니다. 프로그램이 시작하기 전에 무료 -m을 사용하여C 프로그램 malloc 할당이 NULL을 반환하는 이유는 무엇입니까?

void func(...) 
... 
double *PDF; 
... 
PDF = malloc(sizeof(double) * 1); 
if (PDF == NULL) { 
    exit(2); 
} 

, 내가 관찰 :

   total  used  free  shared buffers  cached 
Mem:   2001  1955   46   0   71  975 
-/+ buffers/cache:  907  1094 
Swap:   4008  688  3319 

을하고 프로그램은 종료에 앉아 때 (2); 코드의 라인은 무료 -m 읽 두 경우 모두

   total  used  free  shared buffers  cached 
Mem:   2001  1970   31   0   72  976 
-/+ buffers/cache:  921  1080 
Swap:   4008  688  3319 

, 캐시 행에 사용 가능한 메모리의 많음, (한 바이트 확실히 충분히) 무료 열이있다.

PDF가 NULL이 될 수있는 다른 이유는 무엇입니까? 어떤 코딩 버그가 이것을 일으킬 수 있습니까?

문제가되는 경우 지난 주에 gdb를 많이 사용하여 "q"다음에 "y"를 사용하여 프로그램을 종료했습니다 (프로그램 종료로 인해 모든 malloc 메모리가 해제 될 것이라고 생각 함). 따라서 free() 코드를 실행할 필요가 없습니다.

+0

문제를 재현하는 [SSCCE] (http://sscce.org) 샘플 (main(), includes 및 gcc 플래그)을 볼 수 있습니까? – pilcrow

답변

4

어딘가에 버퍼의 경계를 넘어서 작성한 경우 힙이 손상되었을 수 있습니다.이 경우 모든 베팅이 해제됩니다.

Valgrind가이 일을하지 않았 음을 확인합니다. 호출 프로세스가 더 이상 메모리를 할당 할 수없는 경우

+0

1 바이트 할당을 위해 작동하지 않습니다 (위의 업데이트 된 질문). – ggkmath

+1

@ggkmath : 중요하지 않습니다. 힙이 손상되면 힙이 손상됩니다. –

+0

실제로, 힙을 믿을 수있는 더 많은 이유가 손상되었습니다. –

0

malloc 반환은 일부 메모리 경우에도 그 한계에 도달 할 수 setrlimit

개별 프로세스에 의해 설정된 같은 몇 가지 한계에 도달하기 때문에 아마도 mmap 시스템 호출이 실패하기 때문에, NULL 다른 프로세스에서도 사용할 수 있습니다.

strace을 사용하여 시스템 호출을 추적하고 어느 것이 실패했는지 찾을 수 있습니다.

그리고 gcc -Wall -g으로 컴파일하고 (디버거 gdb 사용).

관련 문제