Python, Java 및 C++를 혼합하여 작성된 우리 프로세스는 때때로 코어 덤프를 수행합니다. 런타임에 필요에 따라 더 많은 메모리를 청크로 할당하고 할당이 4G를 초과하면 충돌이 발생합니다( malloc()반환 값은 확인되지 않습니다).
그러나 GDB에 따르면 결과 코어 덤프는 잘립니다. 운영 체제의 크기에는 제한이 없으며 디스크의 크기는 2~3.8G 사이입니다.
GDB는 크기가 예상한 것과 다르다는 것을 관찰하고(아마도 실패한 할당을 포함합니까?) 포기합니다. 그러나 그것은 확실히 3.8G 데이터에 있습니다.무엇관심이 없나요? 어쩌면 전체 스택을 역추적해야 할 수도 있습니다!
GDB가 적어도 시도하도록 설득할 수 있습니까? 아니면 잘린 코어에서 무언가를 추출할 수 있는 대체 도구가 있습니까?
답변1
Sun Studio 12 웹사이트의 이 광고문은 기본적으로 쓸모가 없다는 것을 암시하는 것 같습니다.
발췌-http://docs.oracle.com/cd/E19205-01/819-5257/blabs/index.html코어 파일이 잘린 경우
코어 파일을 로드하는 데 문제가 있는 경우 코어 파일이 잘렸는지 확인하세요. 코어 파일이 생성될 때 허용되는 최대 코어 파일 크기가 너무 낮게 설정되면 dbx는 잘린 결과 코어 파일을 읽을 수 없습니다. C 셸에서는 제한 명령을 사용하여 허용되는 최대 코어 파일 크기를 설정할 수 있습니다(limit(1) 매뉴얼 페이지 참조). Bourne 쉘 및 Korn 쉘에서는 ulimit 명령을 사용하십시오(limit(1) 매뉴얼 페이지 참조). 셸 시작 파일에서 코어 파일 크기 제한을 변경하고 시작 파일을 다시 시작한 다음 코어 파일을 생성한 프로그램을 다시 실행하여 전체 코어 파일을 생성할 수 있습니다.
코어 파일이 불완전하고 스택 세그먼트가 누락된 경우 스택 추적 정보를 사용할 수 없습니다. 런타임 링커 정보가 손실되면 로드 개체 목록을 사용할 수 없습니다. 이 시나리오에서는 librtld_db.so가 초기화되지 않았다는 오류 메시지가 나타납니다. LWP 목록이 없으면 스레드 정보, lwp 정보 또는 스택 추적 정보를 사용할 수 없습니다. where 명령을 실행하면 프로그램이 "활성"이 아니라는 오류 메시지가 나타납니다.