Le informazioni o il report raccolti vengono caricati su un sistema di tracciamento dei bug.
Se un processo nel sistema si interrompe a causa di un segnale che viene comunemente definito "crash" (violazione della segmentazione, errore del bus, eccezione in virgola mobile, ecc.) O, ad esempio, un'applicazione Python in pacchetto genera un'eccezione non rilevata, il backend apportato viene richiamato automaticamente.
Produce un rapporto iniziale di crash in un file in / var / crash / (il nome del file è composto dal nome dell'eseguibile arrestato e dall'ID utente). Se il processo in crash appartiene all'utente attualmente connesso o appartiene a un processo di sistema e l'utente è un amministratore, apport informa l'utente in merito all'arresto e si offre di segnalare il problema.
Se l'utente lascia abilitata la casella di controllo "Invia segnalazione errori", Apport carica le informazioni raccolte sul sistema di tracciamento dei bug. Dopodiché apre la pagina di archiviazione dei bug dei pacchetti con un ragionevole titolo di errore predefinito e lascia il resto del processo di archiviazione degli errori nell'interfaccia utente web.
Ubuntu riceve un numero incredibilmente elevato di segnalazioni di bug ogni giorno attraverso il nostro sistema di tracciamento dei bug. Ognuno di questi deve essere letto, valutato e ordinato in modo che possa essere risolto. Qui è dove potremmo usare la tua assistenza con Helping With Bugs. Per una rappresentazione visiva del processo di triage dei bug, vedere questi simpatici diagrammi di flusso.
Ogni segnalazione di bug è una conversazione con il reporter. Il primo contatto che un giornalista di solito ha con la comunità di Ubuntu è tramite un triager bug, che cerca di mettere insieme una segnalazione bug completa. È molto importante dare una buona impressione, quindi sii educato e cerca di usare il tuo miglior inglese.
Lavorare su bug semplici e senza alterazioni è un buon modo per iniziare e familiarizzare con la procedura di valutazione poiché dovrai affrontare ogni aspetto del ciclo di vita di un bug. La sezione Bug non modificati spiega dove trovarli.
Tipi di bug
Rapporti di apport
I rapporti sulle app sono bug segnalati tramite il programma di segnalazione automatica dei bug Apport. La segnalazione di bug tramite Apport è il modo preferito di segnalare un bug poiché fornisce agli sviluppatori molte informazioni sul sistema interessato. Quando si utilizza Apport, sono necessarie meno informazioni aggiuntive, accelerando l'intero processo.
È possibile riconoscere questi bug dall'elenco aggiunto di informazioni di sistema nella loro descrizione. Alcuni programmi dispongono di hook per Apport, aggiungendo ulteriori informazioni quando si segnala un bug. Queste informazioni si trovano di solito negli allegati.
Bug confermati
Quando un bug è contrassegnato come "Confermato" non è stato ancora completamente verificato. Questo bug è molto vicino all'essere contrassegnato come "Triaged", ma è necessario assicurarsi che sia pronto per essere risolto dagli sviluppatori.
Richieste di funzionalità
Se la segnalazione di bug è in realtà una richiesta di funzionalità, ci sono due possibilità. Se il miglioramento richiesto è piccolo e ben definito e / o il suggerimento riguarda un progetto a monte, L'importanza del bug dovrebbe essere impostata su "Lista desideri". Quando il rapporto è completo, lo stato deve essere impostato su "Triaged".
Solo i membri del team Ubuntu Bug Control possono farlo. Se non sei un membro dovrai chiedere a qualcuno che lo farà per te. Incollare il numero del bug in # ubuntu-bugs e dire che si pensa che il bug debba essere impostato su 'Wishlist'. Qualcuno lo noterà e lo imposterà per te, anche se non necessariamente immediatamente.
Come funziona internamente?
Intercettazione di crash
Apport utilizza / proc / sys / kernel / core_pattern per reindirizzare direttamente il dump del core in apport:
$ cat /proc/sys/kernel/core_pattern
|/usr/share/apport/apport %p %s %c
$
Nota: anche se ulimit è impostato su file core disabilitati (specificando una dimensione del file core pari a zero usando ulimit -c 0), apport acquisirà comunque l'arresto anomalo. Per intercettare gli arresti anomali di Python, installa un /etc/python*/sitecustomize.pyper chiamare apport su eccezioni non gestite.
Esempio
Apport è anche in grado di acquisire file core se PID 1 (Upstart) muore:
- Se Upstart rileva un'incoerenza interna, genera il segnale SIGABRT.
- Il gestore di crash Upstart viene chiamato su SIGABRT.
- Il gestore di crash di avvio avvia un processo figlio.
- Il processo figlio Upstart genera nuovamente il segnale che provoca l'uscita anomala del bambino.
- Il kernel rileva che il processo figlio è uscito in modo anomalo e chiama apport, eseguendo il piping del file core per apporre l'input standard (a causa di / proc / sys / kernel / core_pattern).
- apport scrive il file core su disco in / var / crash /.
- PID 1 attende che il suo figlio termini (cosa che succede solo quando apport ha finito di scrivere il file principale).
- Il PID 1 esce.
- panico del kernel.
- Al successivo avvio, Whoopsie rileverà il file di arresto e lo elaborerà.
backend
Al fine di mantenere il ritardo e l'impatto CPU / IO il più basso possibile, /usr/share/apport/apportraccoglie solo i dati che devono essere acquisiti mentre esiste ancora il processo bloccato: informazioni da /proc/pid, core dump, percorso eseguibile e numero del segnale. Il rapporto è scritto in /var/crash/executable_path.uid.crash.
Invocazione di frontend
In Gnome, update-notifier mantiene attivo un controllo inotify /var/crash. Ogni volta che c'è qualcosa di nuovo, chiama / usr / share / apport / apport-checkreports. Se ci sono nuovi report, chiama / usr / share / apport / apport-gtk, che è il frontend mostrato negli screenshot sopra.
Il frontend quindi raccoglie informazioni aggiuntive come versioni del pacchetto, checksum dei file del pacchetto o versione del sistema operativo e chiama tutti gli hook del pacchetto corrispondenti. Per disabilitarlo, puoi eseguire gsettings set com.ubuntu.update-notifier show-apport-crashes false (come il tuo normale utente desktop).
Auto-retracer basato su Launchpad
Il data center Canonical gestisce un servizio che ripercorre automaticamente i bug con apport. Contrassegnando i bug in base all'architettura in Launchpad, verrà eseguita una traccia e il tag verrà rimosso. I tag utilizzati sono need-i386-retrace o need-amd64-retrace. Vedi l'annuncio.
Ganci Apport per confezione
È possibile per i pacchetti specificare le informazioni raccolte dal sistema e incluse nella segnalazione di bug. Questi vengono eseguiti da hook aggiunti contenuti nei pacchetti. Per alcuni esempi utili vedi:
- source_xorg.py: aggiunge ulteriori file di registro e dettagli hardware alle segnalazioni di bug
- usplash: ignora gli arresti anomali in percorsi di codice specifici
- source_totem.py - pone domande al giornalista e raccoglie informazioni diverse in base alle risposte
in / usr / share / apport / package-hooks. C'è anche un elenco di pacchetti che forniscono hook utili.
Se una segnalazione di arresto anomalo o bug viene inoltrata tramite apport, i relativi hook verranno eseguiti automaticamente. Se hai già segnalato un bug che è stato archiviato senza apportato e sei interessato alle informazioni di questi hook, puoi chiedere al reporter di bug di utilizzare il valore aggiunto raccogli.
Usa la fonte, Luke!
- È possibile scaricare il tarball upstream dalla pagina del progetto Launchpad o il tarball sorgente Ubuntu dall'archivio Ubuntu.
- apport è sviluppato con il bazar RCS su Launchpad. Se vuoi contribuire ad esso o sviluppare il tuo sistema basato su di esso, puoi ottenere il tuo ramo con bzr get lp: apport for trunk, o debcheckout -a apportato per il ramo di packaging di Ubuntu.
Progetti futuri
Vari miglioramenti delle prestazioni, strumenti migliori per lavorare con i report e integrazione di più lingue (tracce dello stack Mono / Python, messaggi di asserzione, ecc.) Vedere le specifiche pertinenti.
Fonti: Apport , Come triage e Come abilitare Apport
