Linux 개발 코어 덤프 파일 분석 실무 공유

머리말:

임베디드 Linux 개발에서는 코어 덤프 파일을 분석하는 것이 일반적인 방법이며 인터넷에서 관련 사용 튜토리얼을 자주 찾을 수 있습니다. 그러나 멀티 스레드 애플리케이션의 코어 덤프 파일을 분석하는 방법에 대한 기사는 거의 없습니다. 오늘은 제가 실제로 사용하면서 겪은 몇 가지 사례를 공유해 모든 분들께 도움이 되길 바라겠습니다. 코드 및 공간 제한으로 인해 더 뚜렷하다고 생각되는 문제만 설명하고 프레임워크 사고를 사용하여 발생하는 많은 코어 덤프 파일 상황을 해결합니다.

저자: 양심은 여전히 ​​존재합니다

재인쇄 승인 및 구경꾼: WeChat 공개 계정 팔로우를 환영합니다: Hamebayashi-kun

또는 작성자의 개인 WeChat을 추가하세요. become_me

---

플롯 소개:

함수를 디버깅하는 동안 일부 코어 덤프 파일을 생성했는데 다른 프로그램 오류가 발생했습니다. 이번 기회를 통해 모든 분들과 공유하고 싶습니다. 일반적으로 코어 덤프 파일은 널 포인터, 범위를 벗어난 배열, 여러 스레드에 의한 여러 릴리스, 스택 오버플로 등으로 인해 생성될 수 있습니다. 여기에서는 제가 겪은 상황을 바탕으로 몇 가지 대표적인 문제를 선택하고 몇 가지 간단한 해결 방법을 공유합니다.

먼저 그에 따라 디버깅하려면 gdb 도구를 사용해야 합니다. 코어 덤프 파일 분석을 시작하기 전에 gdb의 다양한 명령을 숙지해야 합니다. 다음은 gdb 디버깅에 관해 이전에 제가 쓴 두 가지 기사입니다.

Linux에서 gdb 디버깅을 시작하기 위한 기사 1개(1)

Linux에서 gdb 디버깅을 시작하기 위한 기사 1개(2)

따라서 이 기사에서는 이러한 내용에 대해 자세히 설명하지 않고 코어 덤프 파일을 분석할 때 수행해야 하는 실제 작업에만 중점을 둡니다.

먼저 디버깅 정보가 담긴 실행 파일을 이용하여 디버깅을 해야 합니다.

으아아아

예 1: 포인터 초기화 실패

들어간 후 가장 먼저 bt 명령어를 사용하여 스택 정보를 확인합니다

이 코어 덤프 파일에서 함수의 수신 주소와 클래스 멤버 함수 사이에 명확한 데이터 차이가 있음을 쉽게 확인할 수 있습니다. 이렇게 뻔한 부분에 대해서는 직접적으로 결론을 내린 뒤, 세부적인 내용을 확인해 볼 수 있습니다.

으아아아

프레임 번호로 프레임을 선택하세요. 프레임 번호는 bt 명령을 통해 볼 수 있습니다.

我们查看对应的第 17帧的堆栈信息

通过上面截图我们可以看到在第17帧中 this这个类实体化的地址出现了问题。

为了对比我们又查看了对应20帧的堆栈信息以及对应帧的详细信息

然后我们需要确认该指针是什么什么出现问题的，进行第20帧数据的详细查看。其中我们用p命令查看该类下面的对应的和17帧this的关系，确认gyro_在这个函数执行的时候，地址是否正确。

从上面来看在此处函数执行的时候，对应的gyro的地址还没有变成错误的0x1388。

从这里我们基本可以确认到，函数从 第20帧对应位置执行之后再到17帧的函数的时候，执行函数的地址发生了改变 然后开始进入校对代码的环节。

这个时候校对不是看代码执行的具体情况，因为发生问题的部分已经是被修改了指针地址。所以我们需要从全局去看这个实体类被进行实体化和释放操作的地方。

最终找到了一个出现线程调用先后顺序导致变量没有准备好，出现的死机情况。

示例二：另一个指针问题

进入之后第一件事情 使用 bt命令查看堆栈信息

这个coredump文件在使用bt命令之后发现 此处的堆栈信息看上去都很正常，无法显示出代码在哪里了出现了问题。

这个时候我们就要考虑多线程时候，堆栈信息不一定直接捕获到对应线程，我们需要打开所有线程里面的堆栈信息。

thread apply all bt

除了bt大家也可以打印自己需要的其他信息

thread apply all command //所有线程都执行命令

对应打印出所有线程的堆栈信息之后，我们就进行一点点查看，但是如果你的代码定义了 信号处理函数，例如我使用了 handle_exit进行处理，然后我就在所有线程堆栈信息里面去搜索对应最后面信号处理的函数，再往回查看程序执行的过程。

此时我们发现led一个实体化类的的初始地址出现了问题，最后校验代码，发现了这个bug。

示例三：内存溢出

进入之后第一件事情 使用 bt命令查看堆栈信息

此时发现当前堆栈信息也无法进行定位到问题。

그런 다음 thread apply all bt를 사용했지만 처음에는 해당 hand_exit 함수를 보지 못했습니다

그런 다음 info locals를 사용하여 저장된 지역 변수 정보를 봅니다

info f addr打印通过addr指定帧的信息。info args함수 변수의 값을 인쇄합니다.

info locals 지역 변수 정보를 인쇄합니다.

info catch현재 함수의 예외 처리 정보를 인쇄합니다.

지역 변수에는 포인터 오류나 범위를 벗어난 데이터에 대한 명확한 표시가 없습니다.

그래서 p 명령을 사용하여 프레임 정보에 저장된 변수 정보를 인쇄합니다.

오류율이 높다고 생각되는 이러한 변수 정보를 인쇄하면 판단에 도움이 될 수 있습니다. 그러나 이번 인쇄에서는 문제의 위치를 ​​확인할 방법이 없습니다.

그런 다음 모든 스레드의 스택 정보를 다시 살펴봅니다. 마지막으로 비정상적인 매개변수를 보았습니다. 이 값은 매우 크고 다소 비정상적이었습니다.

그런 다음 해당 소스 코드 위치를 확인합니다. C++ 라이브러리이므로 컴파일 위치에서 코드를 직접 살펴봅니다.

프레임 7에 표시된 정보를 먼저 살펴보세요stl_algobase.h:465

해당 코드 위치를 열어본 결과 **__n** 매개변수가 할당된 공간의 양에 대한 매개변수임을 확인했습니다.

실행 전, 후 다시 보기 stl_Vector.h:343

지금 전달된 __n은 대략 1억보다 큰 단위 값이며, 코드의 실제 작업 위치에는 그렇게 큰 공간 할당이 필요하지 않습니다. 그래서 여기에 문제가 있는 것으로 확인되었습니다. 코드 실행 위치와 해당 변수의 전역 사용을 비교한 결과 기본적으로 멀티 스레드에서 큐를 사용하고 잠금이 제대로 사용되지 않는 것으로 판단됩니다. 극단적인 상황에서 출력 및 입력 작업의 여러 스레드가 동일한 영역에서 수행되므로 이번에는 코드가 충돌하게 됩니다.

결론

제가 공유한 프로젝트의 코어 덤프 파일을 분석한 내용입니다. 더 좋은 아이디어와 요구 사항이 있으면 저를 친구로 추가하여 소통하고 공유해 주세요.

내 기사에 사용된 명령 외에도 더 많은 명령을 사용하여 gbd 디버깅을 지원하여 코어 덤프 파일을 확인할 수도 있습니다. 예를 들어 어셈블리 코드 등을 봅니다. 인터넷에는 gdb 디버깅 명령에 대한 많은 기사가 있습니다. 또한 명령 사용에 도움이 되는 다른 기사를 읽을 수도 있습니다.

위 내용은 Linux 개발 코어 덤프 파일 분석 실무 공유의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!