특정 (로컬) 데이터 파일을로드하거나 저장할 때 크래시 덤프 파일을 분석하고 있습니다. 호출 스택은 충돌시에 파일로드를 실행했음을 보여줍니다.크래시 덤프 파일에 크래시가 발생했을 때 로컬 파일이 필요합니까?
이 데이터 파일을 덤프 파일과 함께 가지고 있어야 충돌을 정확하게 분석해야하는지 궁금합니다. 그것은 파일 이름 등 어떤 식 으로든 포인터에 영향을 미칠 것입니까?
특정 (로컬) 데이터 파일을로드하거나 저장할 때 크래시 덤프 파일을 분석하고 있습니다. 호출 스택은 충돌시에 파일로드를 실행했음을 보여줍니다.크래시 덤프 파일에 크래시가 발생했을 때 로컬 파일이 필요합니까?
이 데이터 파일을 덤프 파일과 함께 가지고 있어야 충돌을 정확하게 분석해야하는지 궁금합니다. 그것은 파일 이름 등 어떤 식 으로든 포인터에 영향을 미칠 것입니까?
아니요, 필요하지 않습니다. gdb로 분석 할 내용은 앱과 충돌시 발생시킨 앱에 사용 된 메모리의 스냅 샷입니다. 따라서 코어 파일과 앱 (바이너리 + 필수 라이브러리) 만 있으면되며 디버깅 정보를 알고리즘에 연결할 수 있도록 최선의 경우 소스 코드가 필요합니다. 모든 포인터, 변수 및 기타 변수는 코어가 덤프되는 순간의 값을가집니다.
업데이트 :하지만 충돌이 발생할 때까지 디버거에서 앱을 대화 형으로 실행할 수도 있습니다. 그렇다면 예, 파일이 필요합니다.
하지만 크래시 덤프 파일을 사용하여 코드를 실행하여 모든 충돌을 조사하는 방법은 아닌가요? 차이점에서 호출 스택 및 변수 값을 검사합니다. 업데이트가 필요하지 않을 때 업데이트가 불분명합니다. – zar
코어 덤프를 조사하는 동안 스택 만 탐색 할 수 있지만 지침을 대화식으로 실행할 수는 없습니다. 즉, 디버거에게 "다음 줄을 실행하십시오"라고 말할 수는 없습니다. 디버거가 작동중인 앱에 연결되어 있거나 (디버거에서 실행 된 경우) 디버거가 크래시를 잡았을 때 설명한 경우에만 사용할 수 있습니다. – dmi
또한 요약합니다. 2 가지 경우가 있습니다 : 1) 사고 후 조사, 2) 온라인 디버깅. 코어 덤프 파일을 언급 한 경우 이것은 1 번입니다. – dmi
크래시 덤프 유형 및 크래시 덤프를 만들 때 사용 된 플래그에 따라 다릅니다. 전체 메모리 덤프에는 응용 프로그램이 충돌 할 당시의 모든 메모리가 있습니다. MINIDUMP_TYPE 플래그는 가능한 것의 인상을줍니다. C++의 경우 일반적으로 .NET 젂체 메모리가 선호되므로 덤프가 도움이됩니다.
덤프 외에 소스 파일과 줄 번호에 대한 정보가있는 PDB 파일을 제외하면 추가 파일이 거의 필요하지 않습니다.
크래시 덤프 파일에는 아무 것도 필요하지 않습니다. 하지만 토마스 웰러 (Thomas Weller)가 말했듯이, 충돌을 이해하기 위해서는 바이너리가 필요할 수도 있습니다. 충돌을 "정확하게"분석하려면 "필요합니까?" 아마도. 아마. 충돌을 일으킨 버그에 달렸습니다. – conio