'core dump'에 해당되는 글 3건

  1. 2018.02.13 :: Kernel Dump Analysis #14
  2. 2010.05.27 :: ABRT 사용하기 (3)
  3. 2009.12.16 :: 커널 덤프분석 업데이트.
Skills/mY Technutz 2018. 2. 13. 23:40

이젠 뭐, 커널에 대한 덤프 분석이라기 보다는

CRASH tool 의 사용법과, 이슈에 따라서 분석을 진행하는 방법에 대한 Guide 가 되어가는 것 같다.

이전엔 주절주절 말을 많이한것 같았는데, 오늘은 주로 코드나 어셈의 흐름을 위주로 설명해 볼까 한다.

시스템이 갑작스럽게 코어와 함께 리붓되었단다.

참고로 현재 이슈는 다른 이슈와 연결되어 발생한 이슈로써,

아직 해결되지는 않은 이슈이며, fc_lport 의 값을 찾기 위한 이유에 대해서 밝히지 않고 있었다.

물론 이어지는 덤프분석이 또 있을 것이며, 거기서 이유가 밝혀질 것이다.

여기서 중요한 부분은 위의 로그에서 빨간색으로 표현한 두줄의 스택로그이다.

현재 의심되는 부분은 RBX 로 들어가는 메모리가 Corruption 되거나 used-after-freed 현상인데,

두줄의 로그를 보았을 경우 used-after-freed 가 되지 않을까 싶다.

이번 경우에는 확실히 used-after-freed 현상이 가장 가깝기 때문이다.

즉, 해제된 것을 다시 사용하거나, Double free race condition 등이 발생하고 있다는 것이다.

물론... 소스코드상에서는 아직 오류를 찾을 수 없는 상황이다.

보다 자세하고 큰 그림은 다음 분석을 통해 함께 그려보도록 하겠다.

'Skills > mY Technutz' 카테고리의 다른 글

Kernel Dump Analysis #16  (0) 2018.02.22
Kernel Dump Analysis #15  (0) 2018.02.19
Kernel Dump Analysis #14  (0) 2018.02.13
Kernel Crash dump Analysis - #13  (0) 2017.12.20
커널이 지원하는 기능을 확인하는 습관.  (1) 2017.02.06
Kexec/Kdump 의 제약사항에 대해서  (4) 2016.01.14
posted by mirr

댓글을 달아 주세요

Skills/mY Technutz 2010. 5. 27. 01:09
일전에 잠깐 소개했던 ABRT 에 대한 핸들링을 좀 간략하게 적어볼까 한다.

일차적으로 CLI 를 이용한 쉘에서의 분석이다.

일단 abrt 는 커널 2.6.30 이후부터 (정확하겐 모르겠다) 즉, RHEL6 에서 기본 크래쉬 관리 도구로 사용되는,

자동 버그 리포팅 툴이다.

이것은 큰 기능은 없지만, 어플리케이션 뿐만아닌, 커널 레벨의 모든 크래쉬를 감지,

코어파일을 생성하여 일련번호를 할당하여 관리할 수 있게 한다.

물론 이걸 이용해 분석도 할 수 있고, 간단하게 bugzilla 등에 리포팅 할 수 도 있다.

이것에 대한 얘기는 총 세개의 글로 나누어 설명할 예정이다.

abrt 의 사용을 위해서는 abrtd 라는 데몬이 실행되야 하며, 특정 커널 이후로는 필수 실행데몬이다.

cli (쉘) 에서의 명령어는 abrt-cli 로, 간단하게 몇가지 옵션위주로 설명하겠다.

[mirr@Mirr Document]$abrt-cli --get-list
0.
    UID        : 500
    UUID       : 7934db0508363522625da8ef236db612fa7af2d3
    Package    : gnome-terminal-2.28.2-1.fc12
    Executable : /usr/bin/gnome-terminal
    Crash Time : 2010년 04월 16일 (금) 오후 12시 14분 35초
    Crash Count: 1
1.
    UID        : 500
    UUID       : 4d66c3c61860827f892facad0e7e38e878ac97c5
    Package    : gnome-screensaver-2.28.3-1.fc12
    Executable : /usr/libexec/gnome-screensaver/slideshow
    Crash Time : 2010년 05월 02일 (일) 오후 09시 54분 24초
    Crash Count: 3
...................................
............중략 ...............

7.
    UID        : 500
    UUID       : 23ab4764de849a8166e74e0a1a51f5b7052d47e6
    Package    : abrt-gui-1.0.9-2.fc12
    Executable : /usr/bin/abrt-applet
    Crash Time : 2010년 05월 08일 (토) 오후 05시 41분 32초
    Crash Count: 1
8.
    UID        : 500
    UUID       : f5694f7625c378966ade0589333c19fd13f74e07
    Package    : compiz-0.8.2-24.fc12
    Executable : /usr/bin/compiz
    Crash Time : 2010년 05월 12일 (수) 오전 09시 09분 43초
    Crash Count: 1
9.
    UID        : 500
    UUID       : c90bebaca19d364eef0c133f742478731cf9f1a1
    Package    : twitux-0.69-4.fc12
    Executable : /usr/bin/twitux
    Crash Time : 2010년 05월 24일 (월) 오전 09시 38분 26초
    Crash Count: 1
10.
    UID        : 500
    UUID       : f04092400057d11de3876cce9246844aa663ee43
    Package    : firefox-3.5.9-2.fc12
    Executable : /usr/lib/firefox-3.5/firefox
    Crash Time : 2010년 05월 26일 (수) 오전 10시 04분 40초
    Crash Count: 1

보다시피 0번부터 발생되고, 감지된 모든 크래쉬를 쭉 나열해 준다.

유저레벨에서도 사용이 가능한점이 특징이다라고 할 수 있고,

루트의 경우 커널크래쉬 혹은 커널 워닝 레벨까지 보여준다 (와우~)

직관적이므로 설명이 깊이는 필요없을거라 생각하지만..

일단 프로그램이 실행된 UID, 그리고 프로그램 코어 발생을 구분해주는 UUID,

문제 유발 프로그램의 패키지, 실행파일, Crash 발생 시간, 그리고 Crash 횟수이다.

자 이제 리스트를 받았으면 내용을 봐야지..

[mirr@Mirr Document]$ abrt-cli --report `UUID` 또는 @Number`
>! crash '@0' is not in database
>! Can't find crash with id @0 in database

뭐 이런식으로 뜨면서 Stack Backtrace 장면이 펼쳐진다.

나오는건 중략하고 대략 vi 명령어 모드로 볼 수 있으며, 나오는건 역시 :q 나 :q! 를 사용하면 빠져나오고,

다음과 같이 버그 리포팅을 묻는다.

No changes were detected in the report.
Report using Bugzilla? [y/N]: n
Skipping...
Report using Logger? [y/N]: n
Skipping...
Crash reported via 0 plugins (0 errors)


매우 간단하지 않는가?

여기서 중요한건 코어에서 뽑을 수 있는 로그.. 즉, Backtrace 부분이 손쉽게 보여진다는 점으로,

이것들만 버그질라등에서 검색해도 많은 힌트를 얻을 수 있다.

버그질라에 보고하기 위해서는 계정이 필요하다.

이제 ABRT 를 이용하여, 손쉽게 버그를 핸들링 및 리포팅 하자.

두번째 장에서는 GUI 로 다뤄 볼 예정이다.

PS : 스프링놋흐에서 좀 더 자세히 작성될 예정이다.




posted by mirr

댓글을 달아 주세요

  1.  Addr  Edit/Del  Reply

    비밀댓글입니다

    2010.06.10 17:17
  2.  Addr  Edit/Del  Reply

    비밀댓글입니다

    2010.06.14 13:46
  3.  Addr  Edit/Del  Reply

    비밀댓글입니다

    2010.06.22 16:06

Skills/System 2009. 12. 16. 19:51
http://mirr.springnote.com/pages/3300377
일단 분석중에 다시 다른 문제들이 생겼는데,

코어덤프내용과 추후에 생겨난 문제는 성질이 서로 달랐다.

먼저 메시지부터 스크린샷으로 보내줬었고,

64기가짜리 coredump 였기때문에 분석에 시간이 걸렸었기때문이다.

메모리 부분을 의심 한 뒤에 코어분석을 해봤더니 스토리지 관련 이슈도 있는것 같았다.

어쨋든 R 사에서 온 답변을 보자면
안녕하세요.

현재 계속 발생되는 상황으로 보아서는 사용하시는 시스템의 메모리에 문제가 있는것으로 보입니다.
설치 미디어를 이용해서 부팅하시면 메뉴중에 memtest가 있습니다.
이것을 이용해서 전체 메모리를 점검할 필요가 있겠습니다. 메모리에 대한 검사를 마치신 후에는
(상당히 오랜 시간이 걸립니다) 파일시스템도 점검해주시기 바랍니다.
또는 하드웨어 업체에서 제공하는 진단툴이 있으면 그것으로 테스트를 하셔도 됩니다.

감사합니다

라네요?? (자랑질??)

저번에 분석했었을땐 경험의 부족으로 인해 헛다리짚은 분석 결과를 내었었는데,

이번엔 동일한 답변을 받아 왠지 뿌듯하달까........

이로써 벌써 네가지의 케이스 완료.

( 모아논 vcore 덤프는 많은데 분석하기가 귀찮다..... )
posted by mirr

댓글을 달아 주세요