사용자로부터 코어 덤프가 있습니다. 기본 프로그램은 dlopen을 통해 선택한 플러그인을로드합니다. 프로세스가 플러그인 모듈에서 중단되었습니다. 사용자는 플러그인의 파일 이름과 중단 된 함수를 포함하는 역 추적을 제공했습니다.dlopen() 'ed 플러그인에서 중단 된 코어 덤프를 어떻게 디버깅합니까?
함수에 전달 된 인수와 같은 데이터를 살펴볼 필요가 있습니다. 플러그인이로드 된 위치를 gdb에 알려주는 방법으로 소스와 데이터를 표시하는 방법을 알아낼 수 있습니까?
소스와 데이터를 표시하는 방법을 파악할 수 있도록 gdb에 플러그인이로드 된 위치를 알려주려면 어떻게해야합니까?
GDB가 자동으로 이 (로드 주소가 core 내부에 포함되어있는) 것을해야한다.
고객의 환경에 맞는 바이너리를 제공하면됩니다. 정확하게입니다. this answer을 참조하십시오.
코어 파일이 양호한 경우 충돌에 대한 호출 스택을 포함해야합니다. 당신은 플러그인 모듈과 함수에서 크래시가 발생했다는 것을 나타 냈습니다. 스택을 '위로'이동하면 충돌 지점과 포함 기능을 볼 수 있습니다. 일반적으로 함수/메소드에 대한 인수를 포함하여 지역 변수를 볼 수 있어야합니다.
간단히 말해, 다른 코어 파일처럼 디버깅하십시오. dlopen에 대한 호출이 성공적으로 완료되면 공유 라이브러리는 시작시로드 된 다른 라이브러리와 거의 비슷하게 보입니다.
bt를 공유하는 경우 좀 더 정확한 포인터를 제공 할 수 있습니다.
러시아어로 기록한대로 로컬 실행 파일 및 공유 라이브러리는 클라이언트와 비트가 같아야합니다. 로컬 버전이 다르면 코어와 실행 파일간에 gdb가 수행하는 매핑이 취소됩니다. 이것은 보통 쓰레기를 발생 시키지만, 때로는 막연하게 정확한 것으로 보이는 스택을 만듭니다. 결과적으로 프로그래머는 잘못된 리드를 추적하는 데 시간을 소비합니다. 이 상황은 실제로 악화되고 있습니다!
채용 - russion과 @ matthew-fisher 나는 프로그램 바이너리가 약간 틀렸음에 틀림 없다고 생각한다. 나는 사용자가 그의 것을 보내도록하고있다. –