malloc free 실패

오늘 C 언어의malloc free 실패 문제에 부딪혔습니다. 프로젝트 코드의 양이 매우 많기 때문에 한참을 포지셔닝한 후에야 DLL 문제라는 것을 발견했습니다. 동적 링크 라이브러리에malloc가 분배한 메모리가 메인 프로그램에서free에 부딪혔을 때 붕괴가 실패했습니다.처음에는 지침이 선을 넘거나 수정된 줄 알았다가 신청으로 바로 바꾼 뒤 free로 곧바로 실패하자 DLL과 메인 프로그램 간 호출 문제가 의심됐다.그래서 흔히 볼 수 있는 실패 문제를 총결하여 후배들이 참고하기 편리하게 하였다.

1. 포인터를 초기화하지 않으면free 실패

이free 오류는 위치를 정하기 쉽다. 즉, 바늘이malloc분배를 성공적으로 실행하지 못하면, 직접free는 반드시 실패할 것이다. 왜냐하면 이 바늘은 아직 초기화되지 않았기 때문이다.예를 들면 다음과 같습니다.
view source
print ? 1 void main() { 2 int * pBuf = NULL; 3 free (pBuf); 4 }

2. 지침 신청 후 수정 후 free 실패

이free 오류는 찾기 어렵다. 실제 프로그램은 아래의 예처럼 간단하지 않기 때문에 신청부터 끝까지 여러 개의 모듈, 대량의 처리 코드 논리를 방출할 수 있다. 바늘의 초기 값이 수정되었다. 즉, 분배된 이 메모리의'문패 번호'가 바뀌면 free는 실패할 것이다.
view source
print ? 1 void main() { 2 int * pBuf = ( int *) malloc (250); 3 pBuf++; 4 free (pBuf); 5 }

3. 메인 프로그램과 DLL을 혼용하는malloc와free

모듈 간의 분배와 방출 분리 디자인은 디자인에서 문제가 있다(적어도 천연은 이렇다고 생각한다). 일반적으로 이런 공유에 대해 공유 메모리 방식을 사용하는 것이 가장 좋다. 즉, 분배와 방출은 모두 같은 측이 관리한다. 비록 우리가 그들에게 분배와 방출 임무를 분리시킬 방법이 있지만.
해결 방법:
1. LIB 라이브러리로 변경하여 정적 링크를 할 수 있으면 LIB 호출 방식으로 변경할 수 있다.
2. 만약에 DLL 호출을 계속 사용한다면 DLL에 이 메모리를 방출하는 함수를 추가하여 메인 프로그램이 호출할 수 있도록 고려할 수 있다.
3. 전역적으로 메모리를 분배할 수 있는 함수(예를 들어 HeapAlloc(GetProcessHeap(), 0,size), HeapFree(GetProcessHeap(), 0,p) 등)를 사용하지만 사용을 권장하지 않기 때문에 구조적으로 조정하는 것이 좋다.

4. 메인 프로그램과 링크 라이브러리의 실행 시 라이브러리 설정이 다르면malloc와free 실패 문제를 일으킬 수 있습니다

예를 들어 메인 프로그램 Project->Setting->C/C++의 Use Run-time liberary는 Debug Multithreaded DLL로 설정하고 모듈의 User Run-time liberary는 Debug Multithreaded로 설정하면 메인 프로그램이 DLL malloc를 통해 free를 방출하는 지침을 호출하는 데 실패하지만 사실 이 때 계속 실행하면 delete DLL 생성 대상도 실패한다.하지만 Debug Multithreaded DLL로 통일하면 문제가 없다.자세한 내용은 error LNK2005: "public: void thiscall 텍스트입니다.