우분투 버그가 그 일을 한 후에는 어떻게됩니까?


14

얼마 전까지 만 버그를보고 apport-bug했거나 ubuntu-bug보고하기 시작했습니다. 그러면 시스템에서 계정으로 런치 패드를 열고 수집 된 정보를 업로드하고 버그 보고서에 더 많은 정보를 추가 할 수 있습니다.

이제 gksudo ubuntu-bug(예를 들어 crash-file을 인수로 사용하여 ) 실행하면 일반적인 버그 대화 상자가 나타납니다.

여기에 이미지 설명을 입력하십시오

그리고 그게 다야.

보고서는 어디로 전송됩니까? 구체적인 상황에서는 사람들이 해당 버그에 대한 보고서를 제출할 수 있었음에도 불구하고 버그 보고서로 런치 패드를 사용하지 않아야합니다.

그래서 :이 보고서는 어디로 보내지고 (아마도) 내 시스템에서 버그 보고서를 어떻게 제출 할 수 있습니까 (관련 파일을 훨씬 쉽게 업로드 할 수 있습니다)

"시스템"이 이것이 이미 존재하는 버그의 복제본이라고 결정했을까요?

답변:


7

기술적으로 ubuntu-bug충돌 보고서를 로컬로 기록합니다. 별도의 프로그램 () whoopsie은 기록 된 보고서를 감시하여 중앙 데이터베이스에 업로드합니다. 중앙 데이터베이스는 중요한 문제를 식별하기 위해 자동으로 그룹화됩니다.

결과 데이터는 Ubuntu 오류 추적기 에 표시됩니다 .

우분투의 오류 보고서 그래프

집계 추세는 공개적으로 제공되며 신뢰할 수있는 개발자는 보고서 세부 정보를 사용할 수 있습니다. 자세한 내용은 Ubuntu Wiki에서 확인할 수 있습니다 .

기본적 ubuntu-bug으로 안정적인 릴리스에서 충돌 보고서에 대한 런치 패드에서 버그를 열지 않지만 원하는 경우 이를 구성 할 수 있습니다 . 변경 한 후을 실행하여 기존 충돌 보고서에 대한 버그를 열 수 있습니다 ubuntu-bug /var/crash/foo.crash.


3

수집 된 정보 또는 보고서는 버그 추적 시스템에 업로드됩니다.

일반적으로 '크래시'(세그먼트 위반, 버스 오류, 부동 소수점 예외 등)라고하는 신호로 인해 시스템의 프로세스가 종료되거나 패키지 된 Python 응용 프로그램이 catch되지 않은 예외를 발생시키는 경우 apport backend 자동으로 호출됩니다.

/ var / crash /의 파일에서 초기 충돌 보고서를 생성합니다 (파일 이름은 충돌 한 실행 파일 이름과 사용자 ID로 구성됩니다). 충돌 된 프로세스가 현재 로그인 한 사용자에게 속해 있거나 시스템 프로세스에 속해 있고 사용자가 관리자 인 경우, apport는 충돌에 대해 사용자에게 알리고 문제보고를 제안합니다.

사용자가 "오류 보고서 보내기"확인란을 활성화 한 경우 Apport는 수집 된 정보를 버그 추적 시스템에 업로드합니다. 그런 다음 합리적인 기본 버그 제목으로 패키지의 버그 신고 페이지를 열고 나머지 버그 신고 프로세스를 웹 UI에 남겨 둡니다.

우분투는 매일 버그 추적 시스템을 통해 엄청나게 많은 수의 버그 보고서를받습니다. 이들 각각은 읽고, 평가하고, 정렬하여 수정 될 수 있어야합니다. 여기서는 버그 해결에 도움을 줄 수 있습니다. 버그 심사 프로세스를 시각적으로 표현하려면이 멋진 순서도를 참조하십시오.

모든 버그 보고서는 기자와의 대화입니다. 리포터가 우분투 커뮤니티와 일반적으로 접촉하는 첫 번째 연락처는 버그 심사관을 통해 이루어지며, 버그 심사관은 완전한 버그 보고서를 작성하려고 시도합니다. 좋은 인상을주는 것이 매우 중요합니다. 예의를 지키고 최고의 영어를 사용하십시오.

간단하고 심사되지 않은 버그에 대한 작업은 버그 수명주기의 모든 측면을 처리해야하기 때문에 심사 절차를 시작하고 익히는 좋은 방법입니다. 평가되지 않은 버그 섹션에서는 버그를 찾을 수있는 위치에 대해 설명합니다.

버그 유형

분류 보고서

Apport 보고서는 자동화 된 버그보고 프로그램 Apport를 통해보고 된 버그입니다. Apport를 사용하여 버그보고는 개발자에게 영향을받는 시스템에 대한 많은 정보를 제공하므로 버그를보고하는 것이 좋습니다. Apport를 사용하면 추가 정보가 덜 필요하므로 전체 프로세스 속도가 빨라집니다.

설명에 추가 된 시스템 정보 목록으로 이러한 버그를 인식 할 수 있습니다. 일부 프로그램에는 Apport에 대한 후크가있어 버그를보고 할 때 더 많은 정보를 추가합니다. 이 정보는 일반적으로 첨부 파일에서 찾을 수 있습니다.

확인 된 버그

버그가 '확인 됨'으로 표시되면 아직 완전히 심사되지 않은 것입니다. 이 버그는 'Triaged'로 표시되기에 가깝지만 개발자가 수정할 준비가되었는지 확인해야합니다.

기능 요청

버그 보고서가 실제로 기능 요청 인 경우 두 가지 가능성이 있습니다. 요청 된 향상이 작고 잘 정의되어 있거나 제안이 업스트림 프로젝트와 관련된 경우 버그의 중요성을 '위시리스트'로 설정해야합니다. 보고서가 완료되면 상태는 'Triaged'로 설정되어야합니다.

Ubuntu Bug Control 팀의 구성원 만 그렇게 할 수 있습니다. 회원이 아닌 경우 다른 사람에게 부탁해야합니다. # ubuntu-bugs에 버그 번호를 붙여넣고 버그를 '위시리스트'로 설정해야한다고 말합니다. 반드시 즉각적인 것은 아니지만 누군가가이를 알아 차리고 설정해 줄 것입니다.

내부적으로 어떻게 작동합니까?

충돌 차단

Apport는 / proc / sys / kernel / core_pattern을 사용하여 코어 덤프를 직접 apport로 파이프합니다.

$ cat /proc/sys/kernel/core_pattern
|/usr/share/apport/apport %p %s %c
$ 

참고 : ulimit가 비활성화 된 코어 파일로 설정되어 있어도 (ulimit -c 0을 사용하여 코어 파일 크기를 0으로 지정) apport는 여전히 충돌을 캡처합니다. 파이썬 충돌을 가로 채기 위해 /etc/python*/sitecustomize.py처리되지 않은 예외에 apport를 호출 합니다 .

PID 1 (업 스타트)이 종료되면 Apport에서 코어 파일을 캡처 할 수도 있습니다.

  1. Upstart가 내부 불일치를 감지하면 SIGABRT 신호를 발생시킵니다.
  2. Upstart 크래시 핸들러는 SIGABRT에서 호출됩니다.
  3. 업 스타트 크래시 핸들러는 하위 프로세스를 분기합니다.
  4. Upstart 자식 프로세스는 신호를 다시 발생시켜 자식이 비정상적으로 종료되게합니다.
  5. 커널은 자식 프로세스가 비정상적으로 종료되었음을 감지하고 apport를 호출하여 코어 파일을 파이핑하여 표준 입력을 할당합니다 (/ proc / sys / kernel / core_pattern으로 인해).
  6. apport는 코어 파일을 / var / crash /의 디스크에 씁니다.
  7. PID 1은 자식이 종료되기를 기다립니다 (apport가 코어 파일 작성을 마친 후에 만 ​​발생 함).
  8. PID 1이 종료됩니다.
  9. 커널 패닉.
  10. 다음 부팅시 Whoopsie는 충돌 파일을 감지하여 처리합니다.

백엔드

지연 및 CPU / IO 영향을 가능한 한 낮게 유지하기 위해 /usr/share/apport/apport충돌 프로세스가 여전히 존재하는 동안 수집해야하는 데이터 ( /proc/pid코어 덤프, 실행 파일 경로 및 신호 번호) 만 수집합니다 . 보고서는에 작성됩니다 /var/crash/executable_path.uid.crash.

프론트 엔드 호출

Gnome에서 update-notifier는 inotify watch를 유지합니다 /var/crash. 새로운 것이있을 때마다 / usr / share / apport / apport-checkreports를 호출합니다. 새 보고서가 있으면 위의 스크린 샷에 표시된 프런트 엔드 인 / usr / share / apport / apport-gtk를 호출합니다.

그런 다음 프런트 엔드는 패키지 버전, 패키지 파일 체크섬 또는 OS 버전과 같은 추가 정보를 수집하고 일치하는 모든 패키지 후크를 호출합니다. 이를 비활성화하려면 gsettings set com.ubuntu.update-notifier show-apport-crashes false를 일반 데스크톱 사용자로 실행할 수 있습니다.

런치 패드 기반 자동 재 추적기

Canonical 데이터 센터는 apport로 버그를 자동으로 추적하는 서비스를 실행합니다. 런치 패드의 아키텍처에 따라 버그에 태그를 지정하면 추적이 수행되고 태그가 제거됩니다. 사용되는 태그는 need-i386-retrace 또는 need-amd64-retrace입니다. 공지 사항을 참조하십시오.

패키지 당 Apport Hook

패키지가 시스템에서 수집되어 버그 보고서에 포함 된 정보를 지정할 수 있습니다. 이는 패키지에 포함 된 apport 후크에 의해 수행됩니다. 유용한 예는 다음을 참조하십시오.

  • source_xorg.py-버그 보고서에 추가 로그 파일 및 하드웨어 세부 사항을 추가합니다
  • usplash-특정 코드 경로의 충돌을 무시합니다
  • source_totem.py-기자에게 질문하고 응답에 따라 다른 정보를 수집합니다

/ usr / share / apport / package-hooks에 있습니다. apport 후크를 제공하는 패키지 목록도 있습니다.

충돌 또는 버그 보고서가 apport를 통해 제출되면 관련 후크가 자동으로 실행됩니다. apport없이 제출 된 버그가 이미보고되었고 이러한 후크의 정보에 관심이있는 경우, 버그보고자에게 apport-collect bugnumber를 사용하도록 요청할 수 있습니다.

루크!

  • Launchpad 프로젝트 페이지에서 업스트림 tarball을 다운로드하거나 Ubuntu 아카이브에서 Ubuntu 소스 tarball을 다운로드 할 수 있습니다.
  • apport는 런치 패드의 시장 RCS로 개발되었습니다. 당신이 그것에 기여하거나 그것을 기반으로 자신의 시스템을 개발하려는 경우, 트렁크에 대한 bzr get lp : apport 또는 우분투 포장 지점에 대한 apport 인 debcheckout을 사용하여 자신의 지점을 얻을 수 있습니다.

향후 계획

다양한 성능 향상, 보고서 작업을위한 향상된 도구 및 더 많은 언어 통합 (Mono / Python 스택 추적, 어설 션 메시지 등) 관련 사양을 참조하십시오.

출처 : Apport , 심사 방법Apport 활성화 방법


이것은 내가 익숙한 프로세스이지만 이제는 마지막 문장이 더 이상 적용되지 않는 것 같습니다. 웹 UI가 열리지 않습니다. 나는 당신의 대답이 제 생각에 떠오른 아이디어로 제 질문을 수정했습니다.
guntbert

웹 UI가 로컬이 아니고 (사용자 측이 아니라) 온라인이라고 생각하지만 확실하지 않습니다.
Mitch

이 소스는 2012 년 11 월에 마지막으로 업데이트되었습니다. 정보 오래 되었을 수 있습니다.
guntbert

나는 그것을 보았지만 아무것도 변경되지 않았기 때문에 업데이트 할 필요가 없다고 생각합니다. 아마도 13.10이 나오면 멀티 장치이므로 변경 사항이있을 것입니다. 최신 Apport는 2012 년 10 월 10 일자 2.61입니다 .
Mitch
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.