malloc/freee

이전에 한 편의 박문 을 쓴 적 이 있 는데 free()가 malloc()반환 포인터 와 일치 하지 않 을 때 붕괴 원인 을 소개 합 니 다.http://liulixiaoyao.blog.51cto.com/1361095/565677
이 블 로그 에 서 는 붕괴 가 포인터 변화 이후 정확 한 메모리 관리 머리 를 찾 지 못 해 발생 한 것 이 라 고 설명 했다.
오늘 한 가지 문제 가 생각 났 습 니 다.스 택 에 있 는 지침 에 대해 지침 의 값 은 변수의 주소 입 니 다.예 를 들 어 10 요소 의 배열 은 p+i 방식 으로 직접 접근 할 수 있 습 니 다.그러면 쌓 여 있 는 메모리 에 대해 똑 같이 malloc(10*sizeof(int)입 니 다.앞 이나 어 딘 가 에 관리 헤드 가 필요 하기 때문에 이 메모리 블록 을 관리 해 야 합 니 다.malloc 가 얻 은 지침 이 가리 키 는 메모리 가 어디 에 있 습 니까?
머리 를 가리 키 면 p+i 방식 으로 오류 가 발생 할 수 있 습 니 다.더미 와 스 택 에서 두 가지 지침 작업 이 서로 다른 결 과 를 나 타 낼 수 있 습 니 다.어떻게 할 수 있 습 니까?
두 가지 표현 을 계속 하려 면 malloc 가 되 돌아 온 결과 가 가리 키 는 메모리 영역 은 머리 를 관리 하 는 구역 을 포함 하지 않 지만 고정된 연산 방식 을 통 해 머리 를 관리 하 는 곳 을 찾 을 수 있 습 니 다.이 작업 은 glibc 가 free()를 호출 할 때 진행 합 니 다.
사실 이 증명 하 듯 이 free 함수 의 소스 코드 는 대체적으로 다음 과 같다.

  
  
  
  

   
   
   
   
void free(void *ptr)    
   
   
   
   
   {   
   
   
   
   
           struct mem_control_block *free;   
   
   
   
   
           free = ptr - sizeof(struct mem_control_block);   
   
   
   
   
           free->is_available = 1;   
   
   
   
   
           return;   
   
   
   
   
   } 
  
  
  
  

머리 를 관리 하 는 구조 체 의 정 의 는 다음 과 같다.

  
  
  
  

   
   
   
   
struct mem_control_block {   
   
   
   
   
 int is_available;     
   
   
   
   
 int size;             
   
   
   
   
 }; 
  
  
  
  

원본 코드 에서 보 듯 이 malloc 가 되 돌아 오 는 포인터 가 실제 사용 가능 한 메모리 주 소 를 가리 키 고 실제 분 배 된 메모리 블록 은 요청 한 size(관리 머리 보다 많 음)보다 크다 고 추측 할 수 있 습 니 다.free 시 머리 크기 를 줄 여 실제 분 배 된 메모리 블록 을 얻 을 수 있 습 니 다.위의 의심 을 해결 할 수 있 습 니 다.
 
그 다음 에 또 다른 문 제 를 일 으 켰 습 니 다.free 함수 에서 우 리 는 실제 메모리 방출 함수 의 호출 을 보지 못 했 습 니 다.(물론 이때 방출 은 free 가 아 닐 것 입 니 다.free 는 glibc 로 이 루어 진 포장 일 뿐 입 니 다)free->is 만 있 습 니 다.available = 1;   이 말 은 약간 실제 적 인 의의 가 있 는데,그 안에 어떤 시기 가 석방 되 었 습 니까?
'is'라 고 하 시 네요.avaliable 은 태그 입 니 다.이 메모리 가 방출 될 수 있 음 을 표시 합 니 다.아무 도 사용 하지 않 습 니 다.후속 적 인 방출 작업 은 운영 체제 에서 정기 적 으로 스 캔 하여 더 이상 사용 하지 않 는 메모리 블록 을 방출 합 니 다.
is_avaliable 은 태그 의 사용 입 니 다.확실 합 니 다.분명 한 일 입 니 다.실제 메모리 방출 은 운영 체제 에서 정기 적 으로 스 캔 하여 방출 되 지만 그렇지 않 습 니 다.
glibc 의 malloc 의 실현 도 사전 배분 전략 이 있다 는 것 을 알 게 되 었 습 니 다.10 바이트 요청 은 100 바이트 심지어 더 많은(구체 적 인 전략 이 알려 지지 않 았 음)을 분배 할 수 있 습 니 다.이곳 의 배분 방출 은 모두 glibc 라 이브 러 리 에서 관리 되 어야 합 니 다.glibc 는 사용자 공간 코드 이 고 사용자 공간 코드 가 분 배 된 메모 리 는 운영 체제 에서 방출 되 지 않 습 니 다.운영 체 제 는 정기 적 으로 메모 리 를 스 캔 하여 방출 하 는 것 이 좋 습 니 다.그러나 그것 은 커 널 등급 을 대상 으로 해 야 합 니 다.예 를 들 어 slab,파일 시스템 page 페이지 캐 시 등 사전 할당 정책 을 사 용 했 습 니 다.사용자 공간 은 시스템 호출 brk 등 을 사용 하여 분 배 된 메모리 공간 은 커 널 에 실제 사용 되 고 커 널 에 의 해 회수 되 지 않 습 니 다.
 
또한,malloc 는 모두 가 알 고 있 는 것 처럼 쌓 아 올 리 는 메모리 가 있 고 쌓 인 공간 은 확대 신청 할 수 있 습 니 다.malloc 가 분 배 된 공간 이 쌓 인 것 이 아니 라 mmap 의 구역 일 수도 있 습 니 다.설명 이 정확 하지 않 을 수도 있 습 니 다.확인 해 야 합 니 다.기록 만 해 야 합 니 다.