FreeBSD에서 다중 프로세스 솔루션을 디버깅하려고합니다. 시스템/어플라이언스가 정지 된 시나리오를 경험할 때 'sysctl debug.panic = 1'을 통해 커널 덤프를 강제 실행했습니다. 의도는 동일한 시점에서 모든 프로세스의 상태를 캡처하는 것이 었습니다. 그러나 나는 사용자 공간 응용 프로그램의 스레드 스택을 조사 할 수 없습니다. 'ps'를 사용하면 모든 사용자 공간 프로세스/스레드를 나열 할 수 있지만 스택 프레임을 설정하고 'bt'를 사용하여 풀 수는 없습니다.FreeBSD에서 커널 코어 덤프에서 userspace 스레드 스택을 추출합니다.
내가 수행하려고 시도하는 것과 같은 것을 달성 할 수 있습니까? OpenVMS 디버거 (IIRC도 windbg)를 통해 사용자 공간 스레드를 들여다 볼 수 있습니다.
DDB를 사용하십시오. 스레드의 추적을 지원합니다. this article을 참조하십시오. 같은 기사에서 사용자 공간 스레드를 추적하는 명령의 이름도 kgdb입니다. 그러나 그것들은 매뉴얼 페이지에는 나와 있지 않다. :-(
. "사람 4 DDB"를 참조하십시오. 즉, textdump과 결합하는 것은 충분히있을 수 있습니다.
함께 작업하는 모든 인 경우 코어, 일들이 조금 더 복잡해집니다
"info threads"는 커널 크래시시 실행 중이던 모든 스레드를 나열합니다. "thread X"다음에 "bt"다음에 커널이 생깁니다. 스레드 스택의 일부분
응용 프로그램의 사용자 영역을 가져 오는 것이 더 어려울 수 있습니다. 가장 쉬운 방법은 gcore 응용 프로그램을 수정하여 i t는 libkvm을 사용하여 주어진 프로세스와 관련된 VM 구조를 파고 본질적으로 프로세스의 코어 덤프를 재구성합니다. 그것은 가능하지만, 바로 사용할 수있는 솔루션이 있다고 생각하지 않습니다.
을 통해 읽으십시오. 어플라이언스에서 ddb를 제거했습니다. 더 힘들어 질 수는 있습니다 ... 먼저 작동하는 ddb를 찾고 내가 얼마나 멀리 갈 수 있는지 보도록하겠습니다. 리눅스에서 크로스 컴파일 된 gdb를 사용하고 있습니다. – hackworks
Regular GDB가 FreeBSD 커널 코어 디버깅에 유용하지 않을 수도 있습니다. 첫째, 모든 커널 코어 포맷이 '표준'은 아닙니다. FreeBSD의 KGDB는 minidumps (요즘의 디폴트)를 처리하는 방법을 알고있는 libkvm과 연결되어 있습니다. 최소한 "sysctl debug.minidump = 0"을 사용하여 미니 덤프를 비활성화해야 생성 된 코어가 다소 정상적인 ELF 형식이됩니다. 그렇다면 코어는 물리적 메모리를 버리고 GDB는 커널 가상 주소를 물리적 주소로 변환하기 위해 libkvm이 필요할 것이다. – ArtemB
고맙습니다. – hackworks