Controllo di qualità - Segnalazione di bug - Informazioni di debug

This page is a translated version of the page QA/BugReport/Debug Information and the translation is 100% complete.

TDF LibreOffice Document Liberation Project Blog comunitari Weblate Nextcloud Redmine Ask LibreOffice Donazione

Other languages:

Questa pagina descrive le Informazioni di debug che potreste fornire agli sviluppatori quando effettuate delle Segnalazioni di bug.

Si tratta di elementi AVANZATI

Non sentitevi obbligati a fornire alcuna di queste informazioni, a meno che

Siate uno sviluppatore/programmatore e conosciate cosa significano questi elementi
Uno sviluppatore o qualcuno del Controllo di qualità vi abbia esplicitamente chiesto di fornire queste informazioni
Siete parte del Gruppo del Controllo di qualità

Informazioni di debug per Sistema operativo

Queste istruzioni sono quasi tutte specifiche per un sistema operativo, quindi il resto di questa pagina è suddiviso per OS.

GNU/Linux

Al fine di produrre questi diversi registri di debug, dovrete prima installare i pacchetti di debug. Consultate la guida di debug per la vostra distribuzione Linux:

Un'altra opzione è quella di eseguire una vostra compilazione di debug usando --enable-debug o --enable-symbols. Quest'ultima non modifica la logica del programma, disabilita le ottimizzazioni e non abilita le asserzioni/i controlli, come invece fa l'opzione --enable-debug.

Una terza opzione è quella di scaricare una compilazione giornaliera di debug ed eseguirla. Si possono trovare qui, nelle cartelle che terminano con -dbg. Siate consapevoli che il file scaricato sarà maggiore di 1.6GB ed estratto occuperà circa 5GB.

GNU/Linux: Come ottenere una backtrace

Una backtrace è utile per analizzare i motivi per cui un'applicazione smette di funzionare o si congela. La backtrace può essere eseguita senza pacchetti di debug, anche se non sarà altrettanto utile, ciononostante potenzialmente può fornire almeno alcune informazioni. Dovreste porre in essere i seguenti passaggi:

NOTA: prima di eseguire LibreOffice in modalità di debug, assicuratevi che gdbtrace.log non esista nella cartella dalla quale state lanciando LibreOffice, altrimenti cancellatelo!

avviate un terminale / shell (in alcune distribuzioni potete premere Ctrl + Alt + T per farlo)
eseguite `$ soffice --backtrace`
se vedete il cursore lampeggiare su di una riga che inizia con `(gdb)`, digitate 'run' e poi premete invio (questo succede quando non è presente un profilo utente)
riproducete il crash o il blocco. Se si tratta di un blocco, dovrete forzare un crash, preciò aprite un'altra console e digitate `$ pkill -15 soffice.bin` o in alternativa digitate `$ xkill` e fate clic sulla finestra di LibreOffice bloccata.
se non venite riportati al prompt predefinito e vi trovate su di una riga con il cursore lampeggiante, se visualizzate una riga che termina con '?? ()' digitate 'c', altrimenti digitate 'bt' e poi premete invio. Se invece siete sulla riga che inizia con `(gdb)`, digitate 'quit' per ritornare al prompt.
un file gdbtrace.log sarà creato nella stessa cartella.
allegate il file gdbtrace.log alla segnalazione di bug.

Potete ignorare gli avvertimenti in merito al rifiuto di caricamento automatico dei file .py. Questi sono abbellimenti di formattazione utili solo durante le sessioni interattive di debug. L'opzione --backtrace dello script soffice esegue gdb con l'opzione -nx, che ignora qualsiasi file .gdbinit e i comandi di caricamento automatico che questi possono contenere.

In alternativa, potete collegare gdb al processo soffice.bin dopo aver avviato LibreOffice. Se avete un solo processo di LibreOffice in esecuzione, potete collegarlo velocemente in questo modo: gdb --pid `pgrep soffice`

GNU/Linux: Come ottenere un log da strace

strace traccia le chiamate di sistema eseguite da un processo. Se c'è un problema relativo all'I/O dei file questo può essere un ottimo modo per rilevare esattamente cosa sta succedendo a livello del sistema operativo. È anche un modo veloce per vedere se il programma continua l'esecuzione e/o si è bloccato e trovare informazioni relative al sistema su cui LibreOffice è in esecuzione.

avviate un terminale
soffice --strace
riproducete il vostro problema
comprimete il file di log: bzip2 strace.log
allegate alla segnalazione di bug il file strace.log.bz2 che viene prodotto.

GNU/Linux: Come ottenere un log ld.so

Per i problemi causati da librerie condivise che non vengono trovate, non si caricano, vengono caricate librerie sbagliate, vanno in crash a causa di conflitti dei simboli esportati nel namespace globale ELF, è spesso utile avere un log da ld.so. L'opzione più utile è LD_DEBUG=libs ma anche LD_DEBUG=files è utile in casi più rari.

rm lddebug* # rimuovete qualsiasi log rimasto dall'ultima volta
LD_DEBUG=libs LD_DEBUG_OUTPUT=lddebug soffice
riproducete il vostro problema
ls -l lddebug*
ci sarà un file per processo; quello di interesse è quello relativo al processo principale soffice.bin, che solitamente è di gran lunga quello con le dimensioni maggiori
allegate il file lddebug.N di dimensioni maggiori alla segnalazione del bug

GNU/Linux: Come ottenere un log Valgrind

Il log valgrind è impagabile per tracciare errori oscuri di corruzione della memoria che altrimenti sarebbero estremamente difficili da trovare. Lo ottiene emulando una CPU. L'aspetto leggermente negativo è che il codice viene eseguito circa ottanta volte (80x) più lentamente, che vi sembrerà lento. L'aspetto positivo è che evidenzia problemi introvabili in qualsiasi altro modo e che le tracce prodotte molto spesso indicano esattamente il problema in un modo che rende piuttosto facile agli sviluppatori risolverlo: la vostra pazienza è molto apprezzata. Valgrind può anche produrre un certo numero di falsi positivi.

installate il pacchetto valgrind
avviate un terminale
soffice --valgrind >& /tmp/valgrind.log
siate pazienti ... 80x è molto più lento ... riproducete il problema.
allegate il file /tmp/valgrind.log alla segnalazione di bug.

Se volete specificare delle opzioni aggiuntive per valgrind, potete usare la variabile d'ambiente VALGRIND_OPTS.

GNU/Linux: Come ottenere una trace callgrind

Una trace callgrind punterà immediatamente il dito verso i pezzi di codice con scarse prestazioni e usa valgrind come modello di CPU, perciò richiedere l'installazione del pacchetto valgrind. Questo tipo di trace fornisce una vista a istogramma gerarchica e navigabile dei punti in cui viene speso il tempo all'interno del codice, questo può essere visualizzato con app come kcachegrind. Le trace di callgrind sono processi intensi per la CPU e LibreOffice sarà eseguito molte volte più lentamente del normale, perciò non dovrebbe essere intraprese da un utente con un PC lento. In aggiunta a un PC veloce, LibreOffice dovrà essere compilato con --enable-symbols e non con --enable-dbgutil o --enable-debug, in quanto le compilazioni di debug si comportano in modo molto anormale rispetto alle prestazioni.

avviate un terminale nella cartella di programma di LibreOffice (es. ~/core/instdir/program)
`$ VALGRIND=callgrind ./soffice`

Se il problema che state tracciando è l'apertura lenta di un documento, potreste voler impostare questa variabile di ambiente per uscire immediatamente dopo l'apertura:

`$ export OOO_EXIT_POST_STARTUP=1`

Dopo aver eseguito la trace ed essere usciti in modo pulito (in sintesi premete ctrl + c solamente una volta! nel terminale), troverete un grosso file denominato: callgrind.out.12345 dove 12345 è il PID. Comprimete questo file e allegatelo alla segnalazione di bug o caricatelo in un posto accessibile allo sviluppatore.

Una compilazione di LibreOffice con --enable-symbols aggiungerà circa altri 10GB al sistema di compilazione esistente, in quanto i simboli saranno aggiunti ai file .so nella cartella instdir e ai file .o nella cartella workdir. I simboli possono essere rimossi eseguendo strip sui file o rimuovendo le cartelle instdir e workdir e ricompilando.

Esiste un modo per velocizzare il tracciamento e far si che includa solo i dati rilevanti:

Lanciate con VALGRIND="callgrind --instr-atstart=no" ./soffice
Preparatevi ad eseguire la cosa che volete tracciare in LibreOffice
In un altro terminale, date il comando callgrind_control -i on
Eseguite ciò che volete tracciare
Nell'altro terminale, date il comando callgrind_control -d
Fermate il tracciamento e fermate l'esecuzione di LibreOffice con callgrind_control -k

Un'alternativa a callgrind è perf. I suoi risultati non sono dettagliati come quelli di callgrind, ma viene eseguito molto più velocemente, potreste preferirlo a callgrind in molti casi.

Windows

Windows: Come ottenere una backtrace

Se avete installato LibreOffice 4.2.0 o maggiore e la vostra versione comprende le funzionalità di debug, esiste un server con i simboli per i test che contiene i relativi simboli di debug. Leggete How to get a backtrace with WinDbg per impostare l'ambiente di debug e potete anche guardare questo video che vi aiuterà a comprendere il processo.

Windows: come ottenere l'output del debug di OpenGL

Scaricate e installate una compilazione con le funzionalità di debug, es.: https://dev-builds.libreoffice.org/daily/master/Win-x86@39/current/
Scaricate e installate cygwin (solo la base minima predefinita): https://cygwin.com/setup-x86_64.exe
Dalla riga di comando di cygwin, date questo comando per impostare la variabile di ambiente per la registrazione del log: set SAL_LOG=+INFO.vcl.opengl+WARN
Potreste voler modificare la cartella in quella di programma di LibreOffice a questo modo: cd "/cygdrive/c/Program Files (x86)/LibreOfficeDev 6/program"
Dalla stessa finestra della riga di comando, lanciate LibreOffice con questo comando (aggiungete il percorso completo, se lo lanciate da fuori della cartella del programma): ./soffice.exe --calc 2> soffice.log

Ora provate a riprodurre il vostro problema con OpenGL. I risultati di debug saranno scritti nel file soffice.log, che potrete allegare alla segnalazione del bug.

Windows: come ottenere l'output del debug di OpenCL

Vedete sopra, ma usate set SAL_LOG=+INFO.opencl+INFO.sc.opencl+WARN come variabile d'ambiente.

Potete anche usare questo programma per stampare le informazioni di OpenCL in un file: http://dev-www.libreoffice.org/opencl/Windows/Opencl%20Info.exe

Windows: eseguire il debug di una falla nelle risorse di GDI ( vcl::Window::dispose() )

Il limite predefinito di oggetti GDI univoci in memoria contemporaneamente è di 10.000 e se LibreOffice lo raggiunge può verificarsi un crash vcl::Window::dispose(). Questo potrebbe essere particolarmente problematico in fase di salvataggio, quando LibreOffice potrebbe creae migliaia di VirtualDevices. Al fine di controllare se avete raggiunto il limite di oggetti GDI in memoria, potete seguire il primo passaggio in questa pagina o usare l'applicazione che si chiama GDI handles.

Nel caso sia confermato il raggiungimento del limite, potete seguire i passaggi 2, 3 e 4 di questa pagina per fornire ulteriori informazioni di debug.

Esempio: Bug 102688

Windows: tracciare una corruzione della memoria con DrMemory

Leggete questa sezione nell'articolo relativo al debug in fase di sviluppo.

Windows: come ottenere una traccia delle prestazioni da ETW

L'Event Tracing per Windows (ETW) è un potente strumento per indagare sui problemi relativi alle prestazioni. UIforETW lo rende semplice da usare. Leggete di più al riguardo sul blog di Bruce Dawson.

Per la profilazione delle prestazioni, dovreste usare una compilazione di rilascio o compilare da soli una versione con --enable-symbols. Le compilazioni eseguite con --enable-debug o --enable-dbgutil NON dovrebbero essere usate. Perciò, non usate le compilazioni giornaliere prodotte da Tinderbox 39.

Istruzioni per configurare UIforETW:

Scaricate la versione più recente di UIforETW
Scompattate l'archivio da qualche parte
Eseguite bin/UIforETW.exe o UIforETW32.exe a seconda in base al numero di bit per cui è stata compilata la vostra versione di LibreOffice
Fate clic su Start Tracing
Avviate LibreOffice e eseguite ciò su cui che volete indagare
A un certo punto salvate i Trace Buffer in UIforETW
Fate clic con il pulsante destro del mouse sulla trace mostrata nella sezione Traces in basso e selezionate Open Trace in WPA 10
In WPA, aprite la voce di menu Trace - Configure symbol paths

Fate clic su + e, se usate una compilazione di rilascio, inserite questo:

CACHE*C:\symbols;SRV*http://dev-downloads.libreoffice.org/symstore/symbols;SRV*http://msdl.microsoft.com/download/symbols

o, se usate una compilazione casalinga, questo:

CACHE*C:\symbols;SRV*http://msdl.microsoft.com/download/symbols

Trace - Load symbols. Fate attenzione che questo richiederà tempo e diversi gigabyte di spazio di archiviazione.
Nel pannello in basso, fate clic a lato di CPU Usage (Sampled). L'impostazione predefinita è "Randomascii inclusive (stack)". Impostatela a Flame by Process, Stack*
Cercate il processo soffice.bin: Fate clic con il pulsante destro del mouse su -> Filter to Selection
Premete Ctrl+Maiusc+G (Display Graph only)
Fate clic sull'icona massimizza
Dall'icona "Select chart type" (tra "Select view preset" e "Quick search"), potete modificare il tipo impostandolo a Flame

Le trace possono essere molto accurate, prendete nota di questa funzionalità di UIforETW: Input tracing: se è impostata a Private o Full tutti i movimenti del mouse e gli eventi dei clic saranno registrati nella trace e visualizzati nel grafico Generic Events. Se è impostata a Full tutti i tasti premuti saranno registrati, mentre se impostata a Private tutte le lettere saranno registrate come ‘A’ e tutti i numeri come ‘0’.

Il trace buffer salvato apparirà come file .etl nella cartella C:\Users\nomeUtente\Documenti\etwtraces. Il file può essere condiviso su Bugzilla affinché gli altri lo esaminino con Windows Performance Analyzer.

macOS

macOS: Come ottenere le informazioni di debug

Le informazioni di debug sono utili per analizzare i motivi per cui un'applicazione va in crash o si blocca. Su macOS, potete ottenere le informazioni di debug standard molto facilmente, senza installare software aggiuntivo. (Queste informazioni comprendono anche una semplice stack trace, priva dei simboli completi, ma che in ogni caso può essere molto utile.)

I passaggi esatti variano a seconda della versione di macOS e delle impostazioni, ma in generale potete ottenere le informazioni di debug come segue:

Quando un'applicazione va in crash, macOS avverte con una finestra di dialogo che dice “LibreOffice si è chiuso inaspettatamente.” e chiede se volete inviare una segnalazione a Apple. Fate clic sul pulsante denominato “Segnala…”. Si apre una finestra più grande con il titolo “Problem Report for LibreOffice”; sotto “Problem Details and System Configuration”, trovate un campo di modifica con un lungo testo che contiene molti dettagli tecnici. Potete semplicemente fare clic su questo lungo testo, premere ⌘ Cmd + a per selezionare tutto il testo, quindi premere ⌘ Cmd + c per copiarlo e poi passare a qualsiasi editor di testo (es. Apple's TextEdit) e premere ⌘ Cmd + v per inserire il testo. Dopodiché potete salvare il testo come nuovo file; la cosa migliore sarebbe usare il formato testo pieno (.txt). Allegate il file alla vostra segnalazione di bug. (NON è necessario che inviate la segnalazione a Apple, perciò fate clic su “Non inviare” nella finestra “Problem Report”.)

Quando un'applicazione si blocca o si congela, potete forzare l'uscita premendo ⌘ Cmd + Alt + Esc. macOS vi avverte con una finestra di dialogo intitolata “Force Quit Applications”, che chiede quale applicazione(i) volete chiudere; nell'elenco, spesso potete riconoscere l'applicazione bloccata o congelata dal suggerimento “(non risponde)”. Selezionatela e fate clic sul pulsante “Forza uscita”. A seconda della configurazione del vostro sistema, vi verrà chiesto se volete inviare una segnalazione a Apple; potete confermare, otterrete la stessa finestra “Problem Report” descritta sopra, e potrete copiare e salvare il testo delle informazioni di debug allo stesso modo.

NB: A seconda delle configurazioni del vostro sistema e del vostro utente, potrebbe esservi o non esservi richiesto di inviare una segnalazione a Apple; potrebbe essere necessario aver effettuato l'accesso come utente amministratore per vedere queste finestre di dialogo.

Se la finestra di dialogo del rapporto è stata visualizzata in precedenza, è possibile trovare rapporti sugli arresti anomali precedenti in:

~/Library/Logs/DiagnosticReports/

Il file sarebbe simile a:

soffice-YYYY-MM-DD-155234.ips

Un modo alternativo è quello di usare l'applicazione Activity Monitor.

Leggendo le istruzioni collegate, la modifica nelle nuove versioni di macOS è che la barra degli strumenti Sample Process è stata spostata. Ora c'è un pulsante … per la barra degli strumenti. Fate clic su quel pulsante e selezionate Sample Process nella finestra che compare.

Problemi con Incolla e con gli appunti

Se ci sono problemi a incollare da un'applicazione esterna, non facilmente ottenibile, come un grosso programma commerciale, il controllo di qualità e gli sviluppatori dovranno fare più fatica per ottenere delle specifiche app per i test. La soluzione è usare il gestore degli appunti per salvare le informazioni copiate da quel programma, in modo che la funzione Incolla possa essere provata in qualsiasi momento senza il programma originario. Si raccomanda di usare un gestione degli appunti che funziona su diversi sistemi operativi, e precisamente CopyQ. Il risultato in formato .cpq dovrebbe essere allegato alla segnalazione di bug.