core대용량 파일이 있으므로 쓰기로 설정하도록 core_pattern설정했습니다 .gzip
나중에 만약에역추적파일을 얻으려면 먼저 gunzip완료해야 하며(시간이 오래 걸립니다!) 그런 다음 core파일을 gdb.
방법이 있는지 알고 싶습니다관로( core또는 생성 중) gdb(또는 이를 얻을 수 있는 다른 프로그램 backtrace). 확인해 보니 gdb이에 대한 옵션이 없는 것 같습니다(그리고 없습니다 ). 이와 같은 것을 만들기 전에 ELF 형식 ( GNU/Linux에서) readelf에 다음과 같은 것이 있는지 알고 싶습니다. 작동하지 못하게 될까요?corex86_64
- 편집하다 -
readelf추적을 생성할 수 있는 소스 코드 및 기타 프로그램을 살펴보면 seek()파일을 전달하고뒤로! 이것이 절대적으로 필요한지, 아니면 필요한 모든 정보를 한 번에 읽고 수집할 수 있는지 잘 모르겠습니다. (파이프에서 읽고 싶기 때문에 탐색은 옵션이 아닙니다!)
답변1
커널 코어 덤프 처리기는 좀비 프로세스에서 역추적을 생성할 수 있습니다.아니요먼저 코어 덤프가 디스크에 기록됩니다.
나는 ABRT가 그렇게 할 수 있다고 생각했습니다. 그러나 패치가 있는 것 같지만 아직 병합되지 않았습니다.
답변2
역추적을 생성하려면 주소별로 메모리 내용을 가져와야 합니다. 코어 파일에서 코어에 내용이 포함된 각 가상 주소는 코어 파일의 특정 오프셋에 위치합니다. 역추적을 생성하는 코드가 조회를 수행할 때 해당 조회의 대상은 해당 오프셋의 주소에 매핑된 메모리 내용의 오프셋입니다.
코어 파일을 스트림으로 처리하는 데 장애가 되는 점은 내용을 가져오는 주소에 해당하는 오프셋이 가져올 때마다 증가할 것으로 예상할 이유가 없다는 것입니다. 거꾸로 본다는 것은 단순히 현재 가져온 콘텐츠가 이전에 가져온 오프셋보다 작은 오프셋을 갖는다는 것을 의미합니다.
아마도 코어 파일에서 역추적을 구성하는 가장 간단한 시나리오는 항상 프레임 포인터를 사용하는 코드로 생성된 코어 파일일 것입니다. 이 경우 메모리 읽기는 스택에서 나오며 프레임 포인터 값(각 스택 프레임에 대해 하나)은 스택 프레임의 연결된 목록과 동등한 것을 제공합니다. 여기서 각 스택 프레임의 다음 단어는 반환 주소입니다( 함수 이름과 오프셋에 매핑될 수 있는 적절한 기호가 있는 경우).
일반적인 코어 파일에서 주소가 증가하면 파일 내에서 오프셋도 증가하며, 프레임 포인터 값의 연결된 목록으로 표시되는 일반적인 트레이스백은 각 연속 프레임에 대해 더 큰 프레임 포인터 주소를 갖습니다. 프레임 포인터를 사용하는 코드에 대한 코어 파일의 간단한 역추적은 먼저 스택 포인터 레지스터의 값에서 스택을 찾은 다음 프레임 포인터 값의 연결된 목록을 반복하여 각 프레임과 관련된 반환 주소를 표시할 수 있습니다. 이 접근 방식에는 상당한 양의 버퍼링이 포함되며, 주로 가상 주소를 파일 오프셋에 매핑하는 데 사용되는 코어 파일 시작 부분 근처의 프로그램 세그먼트 헤더입니다. 아마도 이 접근 방식의 가장 심각한 비효율성은 세그먼트 헤더(및 레지스터 값을 가져오는 데 사용되는 주석)와 관련 스레드 스택 사이의 모든 압축되지 않은 데이터가 무시된다는 것입니다.
프레임 포인터를 사용하지 않는 코드에서 역추적을 생성하는 것은 더 복잡하지만 충분한 데이터가 버퍼링된 경우 가능합니다. 올바른 기호를 사용할 수 있으면 실행 가능성이 더 높으며, 디버깅 기호를 사용할 수 있으면 훨씬 더 실행 가능합니다. 프레임 포인터 시나리오와 마찬가지로 관련 스택에서 데이터를 가져오는 것이 필수적일 수 있습니다.
아마도 가장 좋은 접근 방식은 처음부터 코어 파일을 스트림으로 처리하는 것보다 대용량 코어 파일이 공간을 절약하는 방식을 변경하는 것일 것입니다. 출력의 근본적인 문제 gzip는 임의 액세스를 제공하지 않는다는 것입니다. 코어 파일의 공간 효율적인 표현을 위한 더 나은 옵션은 와 유사한 형식이 될 것입니다. squashfs여기서는 일정한 크기의 블록을 압축하여 임의 액세스가 제공되고 이러한 블록이 색인화되어 지정된 오프셋에서 데이터를 얻으려면 먼저 위치를 찾고 적절한 청크의 압축을 푼 다음 압축되지 않은 데이터 내에서 검색합니다.
squashfsin을 사용할 때의 당면 과제는 표준 입력을 core_pattern호출하는 명확한 방법이 없다는 것입니다 . mksquashfs아마도 이 문제를 해결하는 가장 간단한 방법은 코어 파일이 호출될 수 있을 만큼 오랫동안 압축되지 않은 형식으로 존재하도록 하는 것 입니다 mksquashfs. 이미지에 포함하려면 파일을 거꾸로 보면 간단할 수 있습니다. (확실하지는 않지만 형식을 이해하면 적어도 가능성이 있다는 것을 알 수 있습니다.)squashfsmksquashfssquashfssquashfs
거대한 코어 파일이 포함된 이미지가 있다고 가정할 때 squashfs역추적을 생성하는 도구에 이를 제공하는 한 가지 방법은 mount이미지를 단순화하고 해당 마운트 지점 내에서 관련 경로 이름을 제공하는 것이지만 기본적으로 형식을 처리하도록 애플리케이션을 수정하는 squashfs것도 가능합니다. . 이 접근 방식의 한 가지 장점은 간단한 역추적 외에도 코어 파일에 대한 다른 작업도 사용할 수 있다는 것입니다(핵심 분석의 다음 단계는 각 스레드에 대해 하나씩 여러 역추적을 생성하는 것일 수 있습니다).