나는 하루나 이틀 후에 충돌하는 멀티 쓰레드 프로그램을 운영하고있다. 또한 코어 덤프의 gdb 백 트레이스가 어디에도 연결되지 않습니다. 충돌하는 지점에는 기호가 없습니다.코어 파일이 가상 메모리 이상입니까?
이제 코어 파일을 생성하는 시스템의 물리적 메모리는 3 기가 및 5 기가의 스왑 공간입니다. 그러나 우리가 얻는 핵심 덤프는 약 25 기가입니다. 코어 덤프가 실제로 메모리 덤프가 아닌가? 코어 덤프가 왜 큰가요?
그런 상황에서 디버그하는 방법에 대해 누구보다 더 많은 의견을 나눌 수 있습니까?
64 비트 OS를 실행하는 경우 사용 가능한 실제 메모리 + 스왑 공간의 양을 몇 배 초과하는 파일 기반 매핑을 가질 수 있습니다.
커널 버전 2.6.23부터 Linux는 코어 덤프 파일에 포함될 내용을 제어하기위한 메커니즘을 제공합니다. 코어 덤프 필터입니다. 필터의 값은 (core(5) 맨 페이지를 참조) /proc/<pid>/coredump_filter 파일을 통해 조작 비트 필드 :
0x01) - 익명의 개인 매핑 (예를 들어, 동적으로 할당 된 메모리)0x02) - 무명의 공유 매핑0x04) - 파일 백업 개인 매핑0x08) - 파일이 백업 공유 매핑 (예 : 공유 라이브러리)0x20) - 거대한 페이지기본값은뿐만 아니라 모든 익명의 매핑을 덤핑에 해당 0x33입니다 공유 -
0x40) 개인 거대한 페이지 ELF 헤더 (그러나 커널이 CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS으로 컴파일 된 경우에만)와 사적인 거대한 페이지. 이 파일을 읽으면 필터의 16 진수 값이 반환됩니다. coredump_filter에 새로운 16 진수 값을 쓰면 특정 프로세스의 필터가 변경됩니다. 하나있는 모든 가능한 매핑 덤프 활성화하기 : echo 0x7f > /proc/<pid>/coredump_filter
(<pid> 프로세스의 PID 임) 코어 덤프 필터의 값 fork() 의해 생성 된 자식 프로세스 iherited된다.
일부 Linux 배포는 OS 부트 단계 초기에 init 프로세스의 필터 값을 변경할 수 있습니다. 파일 지원 매핑을 덤프 할 수있게합니다. 그러면 나중에 시작된 모든 프로세스에 영향을 미칩니다.
코어 덤프는 프로세스의 메모리 상태 이상을 포함합니다. 코어 덤프 (Linux의 경우)에 포함 된 기타 정보의 예는 https://stackoverflow.com/a/5321564/91757의 답변을 참조하십시오.
특히, [매핑 된] 파일 (http://www.kernel.org/doc/man-pages/online/pages/man2/mmap.2.html)의 내용을 프로세스의 주소 공간에 포함시킵니다 . 최소한 실행 파일과 사용되는 모든 공유 라이브러리가있을 것이며, 응용 프로그램은 다른 파일도 매핑 할 수 있습니다. – Wyzard
하지만 17 GiB 더 ...그것은 조금 더 많은 것이 아닌가? –
어쩌면 큰 파일이 매핑되었을 수 있습니다. 프로그램이 실행되는 동안'/ proc/$ {pid}/maps'를 확인하십시오. – Wyzard
'cat/proc//coredump_filter'는 00000003을 제공합니다. 파일 기반 개인/공유 매핑은 사용할 수 없습니다. 파일 기반 매핑을 설명하는 링크를 제공 할 수 있습니까? 또한, 64 비트 OS에서 실행 중입니다. –
'mmap (2)'맨 페이지를보십시오. 그러나 아마도 일부 라이브러리의 프로그램은 손대지 않은 매우 큰 가상 할당을 수행합니다. 'malloc (16GiB)'는 단지 작은 부분 만 건드립니다. –
스트레스 테스트이므로 16GB malloc이 아니더라도 1000MB의 malloc 일 수 있습니다. :) 당신은 저에게 이것을 말해 줄 수 있습니까? 현재 프로그램은 VIRT 11.7 GB이고 RES는 2.2 GB입니다. 스왑은 거의 무료입니다 (총 5079032k 중 253312k 사용). 따라서 나머지 (11.7-2.2) GB는 파일 기반 메모리 매핑 된 일부 파일입니다. –