KDE TechBase - User contributions [en]

Development/Tutorials/Debugging/How to create useful crash reports (it)

2010-06-06T08:28:39Z

Panda84: Per la maggior parte dei casi.

{{Template:I18n/Language Navigation Bar|Development/Tutorials/Debugging/How to create useful crash reports}}

== Introduzione ==

Questo documento descrive come riprodurre un backtrace (ovvero una "traccia dell'esecuzione") di applicazioni KDE che vanno in crash. Inizialmente vengono fornite alcune informazioni generali; nel seguito vengono descritte le procedure per ottenere i pacchetti KDE per varie distribuzioni utili a ottenere i backtrace. Queste parti dovrebbero essere sufficienti per la maggior parte dei casi. Ci sono alcune sezioni addizionali su come creare backtrace con il GNU Debugger e con Valgrind, che possono essere utili in alcuni casi.

== Come creare segnalazioni di crash utili ==

Una buona segnalazione di bug nel [http://bugs.kde.org Bugzilla] consiste di due parti: una '''descrizione''' di come riprodurre il crash ed un '''backtrace''' del crash stesso. Se manca uno di questi elementi risulta molto più difficile, se non impossibile, per gli sviluppatori affrontare il problema.

Una descrizione deve consistere di qualcosa più di un solo "si è piantato". È necessario cercare di descrivere qualsiasi cosa venga fatta prima del crash. È stato cliccato su un pulsante, aperto un particolare sito o file che ha causato il problema? Quel piccolo dettaglio che potrebbe sembrare inutile all'utente potrebbe risultare utile allo sviluppatore, quindi è sempre il caso di annotarlo nella segnalazione.

Un articolo approfondito su come scrivere delle buone descrizioni di bug e segnalazioni è disponibile a [http://www.chiark.greenend.org.uk/~sgtatham/bugs.html questo indirizzo], è caldamente consigliato leggerlo prima di effettuare delle segnalazioni.

Il backtrace di un crash non va allegato alla segnalazione; va semplicemente incollato in coda al testo della segnalazione stessa. In questo modo è molto più semplice per gli sviluppatori individuare segnalazioni duplicate dello stesso bug, in quanto la ricerca non avviene anche sul testo degli allegati.

Se si incolla un backtrace in una segnalazione assicurarsi di rimuovere tutte le righe, eccetto un paio, del tipo:

(no debugging symbols found)

dal backtrace, in quanto lo rendono più difficile da leggere.

Sebbene incollare backtrace direttamente sia preferibile rispetto ad aggiungere un allegato, non vanno incollate altre cose come log (valgrind, strace o output del terminale) o esempi di dati (email, file HTML e così via); per queste cose vanno usati gli allegati.

=== Backtrace ===

I backtrace sono essenziali. Possono sembrare senza significato per i non addetti, ma in realtà possono contenere una gran quantità di informazioni utili. Un backtrace descrive quali funzioni sono state chiamate prima del crash, in modo che gli sviluppatori possano tracciare in quale metodo è partito il problema. Ottenere buoni backtrace ha uno svantaggio: [[Development/Tutorials/Debugging/Debugging_symbols|le librerie e gli eseguibili occupano molto più spazio rispetto alla versione ottimizzata]]. È per questo motivo che molte distribuzioni scelgono di installare file senza simboli di debugging, '''cosa che causa la creazione di backtrace inutili''' come questo:

(no debugging symbols found)
Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread -1233848624 (LWP 12212)]
[New Thread -1255081072 (LWP 12820)]
[New Thread -1240921200 (LWP 12819)]
[New Thread -1266680944 (LWP 12818)]
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
0xffffe410 in __kernel_vsyscall ()
#0 0xffffe410 in __kernel_vsyscall ()
#1 0xb6a1210b in ?? () from /lib/tls/i686/cmov/libpthread.so.0
#2 0xb6a85afe in ?? () from /usr/lib/libX11.so.6
#3 0x00000003 in ?? ()
#4 0x082149c0 in ?? ()
#5 0x00003ffc in ?? ()
#6 0x00000000 in ?? ()

Per fortuna non c'è da preoccuparsi, con alcune modifiche è possibile creare backtrace con tutte le informazioni necessarie per le applicazioni KDE.

=== Preparare i pacchetti KDE ===

Se la distribuzione in uso ha pacchetti predisposti per il debugging è necessario installarli.

È facile vedere quali pacchetti di debug manchino guardando il backtrace. Prendiamo in considerazione la seguente linea di una backtrace:

#6 0xb7975bdc in ?? () from /usr/lib/libkmailprivate.so.4

Il simbolo <tt>??</tt> indica che la libreria <tt>libkmailprivate.so.4</tt> è priva di informazioni di debug, che potrebbero essere disponibili in pacchetti di debug separati. In questo caso, è facile capire che è necessario installare i pacchetti di debug per KMail per ottenere un backtrace migliore.

Alcune volte, c'è bisogno di installare più di un pacchetto di debug per ottenere un buon backtrace. Ciò dipende da come le distribuzioni suddividono i pacchetti. Per esempio, per alcune distribuzioni è sufficiente installare il pacchetto per <tt>kdepim</tt> per avere sufficienti informazioni riguardo un crash in KMail, in altre distribuzioni c'è un pacchetto di debug aggiuntivo per KMail.

Qui ci sono le istruzioni che spiegano come ottenere i pacchetti di debug per alcune distribuzioni:

*'''Debian''' - Debian offre pacchetti <tt>-dbg</tt> per creare facilmente backtrace utili. Basta installare il corrispondente pacchetto <tt>-dbg</tt>. ad esempio <tt>kdepim-dbg</tt> per i crash di KMail. Le dipendenze di -dbg assicurano di ottenere anche gli altri pacchetti necessari (kdelibs-dbg, gdb, e così via).
*'''FreeBSD ports''' - Fare riferimento alla pagina [http://freebsd.kde.org/faq.php#AKDEapplicationcrashedandIwanttofileabugreportathttpbugskdeorgbutthebacktraceintheKDECrashManagerisuselessWhatcanIdo delle FAQ di KDE su FreeBSD].
*'''Gentoo''' - Gentoo ha [http://www.gentoo.org/proj/en/qa/backtraces.xml una guida] che descrive come procedere.
*'''Mandriva''' - A partire da Mandriva 2007.0 in su ci sono pacchetti addizionali per tutto KDE. È sufficiente installare il corrispondente pacchetto <tt>-debug</tt>, come <tt>kdebase-debug</tt> e <tt>kdemultimedia-debug</tt>. Quasi certamente va installato <tt>kdelibs-debug</tt> in ogni caso.
** Nota: i pacchetti <tt>-debug</tt> sono in repository separati. Ad esempio, per tutti i pacchetti in <tt>main</tt>, si possono trovare i pacchetti di debug nel repository <tt>debug_main</tt>.
*'''Kubuntu/Ubuntu''' - La famiglia di distribuzioni Ubuntu rende le cose abbastanza facili. Ogni modulo ufficiale di KDE ha un pacchetto aggiuntivo nei repository con il suffisso <tt>-dbg</tt>. È importante installare sempre <tt>kdelibs5-dbg</tt>, in quanto tutte le applicazioni KDE usano kdelibs (kdelibs-dbg per applicazioni KDE 3). Oltre a ciò è necessario installare il pacchetto -dbg anche per l'applicazione che è andata in crash. Per esempio se si è piantato KOrganizer è necessario installare anche <tt>kdepim-dbg</tt>. Se il programma non fa parte di un modulo ufficiale di KDE e non ha un apposito pacchetto -dbg, è possibile installare il pacchetto -dbgsym dal repository in questa [https://wiki.kubuntu.org/DebuggingProgramCrash pagina sul debugging dei programmi].
** Durante il ciclo di sviluppo di Ubuntu il gestore di crash Apport è attivo e si preoccuperà di riportare i crash a launchpad.net e creare il backtrace per te. Se si desidera utilizzare il gestore dei crash di KDE è possibile disabilitarlo nel file /etc/defaults/apport
** A partire da Lucid Lynx (10.04) Kubuntu inoltrerà tutti i bug che non sono peculiari della distribuzione al sistema di gestione di KDE; Apport è ora disabilitato in modo da utilizzare DrKonqui come gestore predefinito dei crash.
*'''openSUSE''' - È necessario solo installare i pacchetti <tt>-debuginfo</tt>, ad esempio: <tt>kdepimlibs4-debuginfo</tt>. È possibile trovare questi pacchetti nei [http://en.opensuse.org/KDE/Repositories repository KDE]. C'è anche una [http://en.opensuse.org/Bugs:An_application_crashed pagina dedicata al debugging in openSUSE].
*'''Fedora''' - In Fedora è sufficiente utilizzare i seguenti comandi:
*# <tt>yum provides "/usr/lib/libkmailprivate.so.4"</tt> per trovare quale pacchetto fornisce quel file;
*# <tt>debuginfo-install kdepim</tt> da utente root per installare i pacchetti di debug per quel pacchetto (dipendenze incluse).
*: Una guida completa e dettagliata per Fedora è disponibile in [http://fedoraproject.org/wiki/StackTraces questo documento] che descrive come procedere. Fedora utilizza un repository debuginfo separato che va abilitato. Si consiglia anche di utilizzare il plugin yum <tt>auto-update-debug-info</tt> per tenere aggiornati i pacchetti debuginfo.

Nel raro caso in cui la distribuzione non abbia pacchetti contenenti i simboli di debug per KDE, è necessario compilare KDE dai sorgenti:

* Nel caso di KDE 3, al passo di configure, è necessario passare il parametro <tt>--enable-debug=full</tt> al fine di creare i simboli di debug nei file risultanti.
* Nel caso di KDE 4, al passo di cmake, è necessario passare il parametro <tt>-DCMAKE_BUILD_TYPE=debugfull</tt>. Se si vuole passare opzioni personalizzate a CXXFLAGS, utilizzare <tt>-DCMAKE_BUILD_TYPE=None CMAKE_CXX_FLAGS="-O0 -g"</tt>. È possibile cambiare le opzioni CMAKE_CXX_FLAGS in base alle proprie necessità.

Dopodiché è sufficiente dare <tt>make</tt> e <tt>make install</tt> come al solito.

===Crash!===

Ora che sono state reperite le informazioni per rendere utile la traccia dell'esecuzione va riprodotto il crash nell'applicazione. La finestra di dialogo di KDE apparirà qualche istante dopo al crash dell'applicazione.

[[Image:Kde-crash-handler.png|center|300px|La finestra di dialogo dei crash di KDE]]

Ora la generazione del backtrace dovrebbe risultare molto più completa, ad esempio:

Using host libthread_db library "/lib/libthread_db.so.1".
[Thread debugging using libthread_db enabled]
[New Thread -1232783168 (LWP 7604)]
[KCrash handler]
#6 0x0806be76 in TreeMapItem::parent (this=0x0)
at /home/bram/KDE/kde3/kdeaddons/konq-plugins/fsview/treemap.h:285
#7 0x08065fea in TreeMapItemList::compareItems (this=0xbfec04a8, item1=0x0,
item2=0x0)
at /home/bram/KDE/kde3/kdeaddons/konq-plugins/fsview/treemap.cpp:720
#8 0xb7281619 in QGList::operator== () from /usr/qt/3/lib/libqt-mt.so.3
#9 0x0806d498 in QPtrList<TreeMapItem>::operator== (this=0xbfec04a8,
list=@0xbfec0468) at /usr/qt/3/include/qptrlist.h:74
#10 0x08062e18 in TreeMapWidget::mousePressEvent (this=0xbfec03ac,
e=0xbfebff1c)
at /home/bram/KDE/kde3/kdeaddons/konq-plugins/fsview/treemap.cpp:1840
#11 0xb7004a63 in QWidget::event () from /usr/qt/3/lib/libqt-mt.so.3
#12 0xb6f6bca7 in QApplication::internalNotify ()
from /usr/qt/3/lib/libqt-mt.so.3
#13 0xb6f6ca88 in QApplication::notify () from /usr/qt/3/lib/libqt-mt.so.3
#14 0xb7725a84 in KApplication::notify (this=0xbfec055c, receiver=0xbfec03ac,
event=0xbfebff1c)
at /home/bram/KDE/kde3/kdelibs/kdecore/kapplication.cpp:550
#15 0xb6f0bfd2 in QETWidget::translateMouseEvent ()
from /usr/qt/3/lib/libqt-mt.so.3
#16 0xb6f0b8b0 in QApplication::x11ProcessEvent ()
from /usr/qt/3/lib/libqt-mt.so.3
#17 0xb6f1b761 in QEventLoop::processEvents () from /usr/qt/3/lib/libqt-mt.so.3
#18 0xb6f82831 in QEventLoop::enterLoop () from /usr/qt/3/lib/libqt-mt.so.3
#19 0xb6f826b6 in QEventLoop::exec () from /usr/qt/3/lib/libqt-mt.so.3
#20 0xb6f6b72f in QApplication::exec () from /usr/qt/3/lib/libqt-mt.so.3
#21 0x0805181e in main (argc=134673960, argv=0xffffffff)
at /home/bram/KDE/kde3/kdeaddons/konq-plugins/fsview/main.cpp:55

Molto meglio, vero? In questo backtrace sono presenti gli indirizzi di memoria, i file sorgenti, i numeri di riga e i parametri passati alle funzioni che hanno causato il problema. Ciò rende più facile per gli sviluppatori capire la causa del problema, in quanto sanno dove guardare.

{{note|È '''obbligatorio''' avere GDB installato per ottenere il backtrace di un crash. Nella sezione seguente è spiegato cos'è GDB e come installarlo.}}

===Ottenere un backtrace con GDB===

In alcuni casi non è possibile creare un backtrace con la finestra di dialogo dei crash di KDE. Ciò può essere dovuto da un'applicazione entrata in un loop infinito, o dal fatto che la finestra del crash non è apparsa per qualche motivo. In tali casi è possibile ottenere un backtrace con <tt>gdb</tt>, il [http://sourceware.org/gdb/ Debugger GNU]. GDB è disponibile pacchettizzato per tutte le distribuzioni più importanti.

Il richiamo di GDB dipende dalle situazioni. È possibile sia eseguire un'applicazione all'interno di gdb che collegare gdb ad un processo già in esecuzione. Quest'ultima situazione in particolare è utile quando un'applicazione è già entrata in un loop infinito. Cominciamo con la prima soluzione; per eseguire un'applicazione da gdb digitare sulla riga di comando:

$ gdb someKDEapp

Apparirà il prompt di GDB. Per avviare l'applicazione, al momento non ancora avviata, è necessario invocare il comando<tt>run</tt>:

(gdb) run

{{note|Alcune applicazioni di KDE (ad esempio JuK e KTorrent) contengono del codice speciale per assicurarsi che ci sia una sola istanza dell'applicazione avviata alla volta. Per queste applicazioni bisogna utilizzare il comando "run --nofork" al prompt di (gdb) invece di "run" perché altrimenti gdb proverebbe a debuggare il processo sbagliato. In caso di dubbio su quale usare è sufficiente provare ad avviare l'applicazione con l'opzione --nofork: se l'applicazione dice che è un'opzione sconosciuta è possibile rimuovere l'opzione --nofork.}}

Questo avvierà l'applicazione a cui siete abituati, e vi permetterà di lavorarci come fate solitamente (con la differenza che consumerà molta più memoria e potrebbe risultare molto più lenta). Ora va riprodotto il crash. Quando l'applicazione va in crash essa si chiuderà riportando al prompt di GDB. Ora è necessario invocare il comando 'backtrace':

(gdb) thread apply all backtrace

Ciò dovrebbe fornire una buona backtrace che può essere inserita nel Bugzilla di KDE.

In caso si voglia collegarsi ad un processo già esistente va invocato il seguente comando:

$ gdb someKDEapp pid

dove ''pid'' è il process ID del processo al quale ci si vuole collegare. Una volta collegati, quando il processo è in un ciclo infinito, dopo aver usato il comando 'backtrace' apparirà una traccia dell'esecuzione. È possibile utilizzare il comando 'continue' per lasciare l'applicazione eseguire nuovamente e premere Ctrl+C in gdb per poter inserire nuovamente dei comandi.

===Ottenere un backtrace con Valgrind===

Un altro strumento utile per creare backtrace di crash è [http://www.valgrind.org Valgrind]; esso non sostituisce GDB, ma piuttosto lo completa.

Quando si esegue un'applicazione in valgrind ogni pezzo di memoria letta o scritta dall'applicazione stessa viene controllato. Valgrind riporterà operazioni non valide in memoria nello standard output o in un file di log. Dato che la maggior parte dei crash sono dovuti a letture invalide in memoria, Valgrind può essere utile per tracciare dove succedono i problemi.

{{note|Valgrind consiste di vari tool per verificare o effettuare la profilazione di un'applicazione. In questo articolo useremo solo memcheck, il tool di default che viene chiamato all'esecuzione di valgrind.}}

Come GDB, Valgrind rende l'esecuzione delle applicazioni molto più lento e più esoso in termini di risorse.

Per avviare l'applicazione all'interno di valgrind:

$ valgrind --log-file=someKDEapp someKDEapp

Ora va riprodotto il crash. Appena avviene sia l'applicazione che valgrind termineranno. Ciò che rimane è un file con nome <tt>someKDEapp.pid</tt> dove ''pid'' sarà il process ID del processo valgrind. Il file potrebbe elencare più errori di quanti siano effettivamente causa del crash. Qui c'è un esempio della parte che causa il crash che corrisponde al backtrace GDB sopra:

==23292== Invalid read of size 4
==23292== at 0x806BD9E: TreeMapItem::parent() const (treemap.h:285)
==23292== by 0x8065FB9: TreeMapItemList::compareItems(void*, void*) (treemap.cpp:720)
==23292== by 0x50AC618: QGList::operator==(QGList const&) const (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== by 0x806D3BF: QPtrList<TreeMapItem>::operator==(QPtrList<TreeMapItem> const&) const (qptrlist.h:74)
==23292== by 0x8062DE7: TreeMapWidget::mousePressEvent(QMouseEvent*) (treemap.cpp:1840)
==23292== by 0x4E2FA62: QWidget::event(QEvent*) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== by 0x4D96CA6: QApplication::internalNotify(QObject*, QEvent*) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== by 0x4D97A87: QApplication::notify(QObject*, QEvent*) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== by 0x4809AC3: KApplication::notify(QObject*, QEvent*) (kapplication.cpp:550)
==23292== by 0x4D36FD1: QETWidget::translateMouseEvent(_XEvent const*) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== by 0x4D368AF: QApplication::x11ProcessEvent(_XEvent*) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== by 0x4D46760: QEventLoop::processEvents(unsigned) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== Address 0x2C is not stack'd, malloc'd or (recently) free'd

Per essere sicuro allega alla segnalazione del bug l'intero file log fornito da valgrind.

Development/Tutorials/Debugging/How to create useful crash reports (it)

2010-06-05T10:39:21Z

Panda84: moved User:Panda84/Development/Tutorials/Debugging/How to create useful crash reports (it) to Development/Tutorials/Debugging/How to create useful crash reports (it): Page is now completely translated. La pagina è ora completamente tradotta.

{{Template:I18n/Language Navigation Bar|Development/Tutorials/Debugging/How to create useful crash reports}}

== Introduzione ==

Questo documento descrive come riprodurre un backtrace (ovvero una "traccia dell'esecuzione") di applicazioni KDE che vanno in crash. Inizialmente vengono fornite alcune informazioni generali; nel seguito vengono descritte le procedure per ottenere i pacchetti KDE per varie distribuzioni utili a ottenere i backtrace. Queste parti dovrebbero essere sufficienti per la maggior parte della gente. Ci sono alcune sezioni addizionali su come creare backtrace con il GNU Debugger e con Valgrind, che possono essere utili in alcuni casi.

== Come creare segnalazioni di crash utili ==

Una buona segnalazione di bug nel [http://bugs.kde.org Bugzilla] consiste di due parti: una '''descrizione''' di come riprodurre il crash ed un '''backtrace''' del crash stesso. Se manca uno di questi elementi risulta molto più difficile, se non impossibile, per gli sviluppatori affrontare il problema.

Una descrizione deve consistere di qualcosa più di un solo "si è piantato". È necessario cercare di descrivere qualsiasi cosa venga fatta prima del crash. È stato cliccato su un pulsante, aperto un particolare sito o file che ha causato il problema? Quel piccolo dettaglio che potrebbe sembrare inutile all'utente potrebbe risultare utile allo sviluppatore, quindi è sempre il caso di annotarlo nella segnalazione.

Un articolo approfondito su come scrivere delle buone descrizioni di bug e segnalazioni è disponibile a [http://www.chiark.greenend.org.uk/~sgtatham/bugs.html questo indirizzo], è caldamente consigliato leggerlo prima di effettuare delle segnalazioni.

Il backtrace di un crash non va allegato alla segnalazione; va semplicemente incollato in coda al testo della segnalazione stessa. In questo modo è molto più semplice per gli sviluppatori individuare segnalazioni duplicate dello stesso bug, in quanto la ricerca non avviene anche sul testo degli allegati.

Se si incolla un backtrace in una segnalazione assicurarsi di rimuovere tutte le righe, eccetto un paio, del tipo:

(no debugging symbols found)

dal backtrace, in quanto lo rendono più difficile da leggere.

Sebbene incollare backtrace direttamente sia preferibile rispetto ad aggiungere un allegato, non vanno incollate altre cose come log (valgrind, strace o output del terminale) o esempi di dati (email, file HTML e così via); per queste cose vanno usati gli allegati.

=== Backtrace ===

I backtrace sono essenziali. Possono sembrare senza significato per i non addetti, ma in realtà possono contenere una gran quantità di informazioni utili. Un backtrace descrive quali funzioni sono state chiamate prima del crash, in modo che gli sviluppatori possano tracciare in quale metodo è partito il problema. Ottenere buoni backtrace ha uno svantaggio: [[Development/Tutorials/Debugging/Debugging_symbols|le librerie e gli eseguibili occupano molto più spazio rispetto alla versione ottimizzata]]. È per questo motivo che molte distribuzioni scelgono di installare file senza simboli di debugging, '''cosa che causa la creazione di backtrace inutili''' come questo:

(no debugging symbols found)
Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread -1233848624 (LWP 12212)]
[New Thread -1255081072 (LWP 12820)]
[New Thread -1240921200 (LWP 12819)]
[New Thread -1266680944 (LWP 12818)]
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
0xffffe410 in __kernel_vsyscall ()
#0 0xffffe410 in __kernel_vsyscall ()
#1 0xb6a1210b in ?? () from /lib/tls/i686/cmov/libpthread.so.0
#2 0xb6a85afe in ?? () from /usr/lib/libX11.so.6
#3 0x00000003 in ?? ()
#4 0x082149c0 in ?? ()
#5 0x00003ffc in ?? ()
#6 0x00000000 in ?? ()

Per fortuna non c'è da preoccuparsi, con alcune modifiche è possibile creare backtrace con tutte le informazioni necessarie per le applicazioni KDE.

=== Preparare i pacchetti KDE ===

Se la distribuzione in uso ha pacchetti predisposti per il debugging è necessario installarli.

È facile vedere quali pacchetti di debug manchino guardando il backtrace. Prendiamo in considerazione la seguente linea di una backtrace:

#6 0xb7975bdc in ?? () from /usr/lib/libkmailprivate.so.4

Il simbolo <tt>??</tt> indica che la libreria <tt>libkmailprivate.so.4</tt> è priva di informazioni di debug, che potrebbero essere disponibili in pacchetti di debug separati. In questo caso, è facile capire che è necessario installare i pacchetti di debug per KMail per ottenere un backtrace migliore.

Alcune volte, c'è bisogno di installare più di un pacchetto di debug per ottenere un buon backtrace. Ciò dipende da come le distribuzioni suddividono i pacchetti. Per esempio, per alcune distribuzioni è sufficiente installare il pacchetto per <tt>kdepim</tt> per avere sufficienti informazioni riguardo un crash in KMail, in altre distribuzioni c'è un pacchetto di debug aggiuntivo per KMail.

Qui ci sono le istruzioni che spiegano come ottenere i pacchetti di debug per alcune distribuzioni:

*'''Debian''' - Debian offre pacchetti <tt>-dbg</tt> per creare facilmente backtrace utili. Basta installare il corrispondente pacchetto <tt>-dbg</tt>. ad esempio <tt>kdepim-dbg</tt> per i crash di KMail. Le dipendenze di -dbg assicurano di ottenere anche gli altri pacchetti necessari (kdelibs-dbg, gdb, e così via).
*'''FreeBSD ports''' - Fare riferimento alla pagina [http://freebsd.kde.org/faq.php#AKDEapplicationcrashedandIwanttofileabugreportathttpbugskdeorgbutthebacktraceintheKDECrashManagerisuselessWhatcanIdo delle FAQ di KDE su FreeBSD].
*'''Gentoo''' - Gentoo ha [http://www.gentoo.org/proj/en/qa/backtraces.xml una guida] che descrive come procedere.
*'''Mandriva''' - A partire da Mandriva 2007.0 in su ci sono pacchetti addizionali per tutto KDE. È sufficiente installare il corrispondente pacchetto <tt>-debug</tt>, come <tt>kdebase-debug</tt> e <tt>kdemultimedia-debug</tt>. Quasi certamente va installato <tt>kdelibs-debug</tt> in ogni caso.
** Nota: i pacchetti <tt>-debug</tt> sono in repository separati. Ad esempio, per tutti i pacchetti in <tt>main</tt>, si possono trovare i pacchetti di debug nel repository <tt>debug_main</tt>.
*'''Kubuntu/Ubuntu''' - La famiglia di distribuzioni Ubuntu rende le cose abbastanza facili. Ogni modulo ufficiale di KDE ha un pacchetto aggiuntivo nei repository con il suffisso <tt>-dbg</tt>. È importante installare sempre <tt>kdelibs5-dbg</tt>, in quanto tutte le applicazioni KDE usano kdelibs (kdelibs-dbg per applicazioni KDE 3). Oltre a ciò è necessario installare il pacchetto -dbg anche per l'applicazione che è andata in crash. Per esempio se si è piantato KOrganizer è necessario installare anche <tt>kdepim-dbg</tt>. Se il programma non fa parte di un modulo ufficiale di KDE e non ha un apposito pacchetto -dbg, è possibile installare il pacchetto -dbgsym dal repository in questa [https://wiki.kubuntu.org/DebuggingProgramCrash pagina sul debugging dei programmi].
** Durante il ciclo di sviluppo di Ubuntu il gestore di crash Apport è attivo e si preoccuperà di riportare i crash a launchpad.net e creare il backtrace per te. Se si desidera utilizzare il gestore dei crash di KDE è possibile disabilitarlo nel file /etc/defaults/apport
** A partire da Lucid Lynx (10.04) Kubuntu inoltrerà tutti i bug che non sono peculiari della distribuzione al sistema di gestione di KDE; Apport è ora disabilitato in modo da utilizzare DrKonqui come gestore predefinito dei crash.
*'''openSUSE''' - È necessario solo installare i pacchetti <tt>-debuginfo</tt>, ad esempio: <tt>kdepimlibs4-debuginfo</tt>. È possibile trovare questi pacchetti nei [http://en.opensuse.org/KDE/Repositories repository KDE]. C'è anche una [http://en.opensuse.org/Bugs:An_application_crashed pagina dedicata al debugging in openSUSE].
*'''Fedora''' - In Fedora è sufficiente utilizzare i seguenti comandi:
*# <tt>yum provides "/usr/lib/libkmailprivate.so.4"</tt> per trovare quale pacchetto fornisce quel file;
*# <tt>debuginfo-install kdepim</tt> da utente root per installare i pacchetti di debug per quel pacchetto (dipendenze incluse).
*: Una guida completa e dettagliata per Fedora è disponibile in [http://fedoraproject.org/wiki/StackTraces questo documento] che descrive come procedere. Fedora utilizza un repository debuginfo separato che va abilitato. Si consiglia anche di utilizzare il plugin yum <tt>auto-update-debug-info</tt> per tenere aggiornati i pacchetti debuginfo.

Nel raro caso in cui la distribuzione non abbia pacchetti contenenti i simboli di debug per KDE, è necessario compilare KDE dai sorgenti:

* Nel caso di KDE 3, al passo di configure, è necessario passare il parametro <tt>--enable-debug=full</tt> al fine di creare i simboli di debug nei file risultanti.
* Nel caso di KDE 4, al passo di cmake, è necessario passare il parametro <tt>-DCMAKE_BUILD_TYPE=debugfull</tt>. Se si vuole passare opzioni personalizzate a CXXFLAGS, utilizzare <tt>-DCMAKE_BUILD_TYPE=None CMAKE_CXX_FLAGS="-O0 -g"</tt>. È possibile cambiare le opzioni CMAKE_CXX_FLAGS in base alle proprie necessità.

Dopodiché è sufficiente dare <tt>make</tt> e <tt>make install</tt> come al solito.

===Crash!===

Ora che sono state reperite le informazioni per rendere utile la traccia dell'esecuzione va riprodotto il crash nell'applicazione. La finestra di dialogo di KDE apparirà qualche istante dopo al crash dell'applicazione.

[[Image:Kde-crash-handler.png|center|300px|La finestra di dialogo dei crash di KDE]]

Ora la generazione del backtrace dovrebbe risultare molto più completa, ad esempio:

Using host libthread_db library "/lib/libthread_db.so.1".
[Thread debugging using libthread_db enabled]
[New Thread -1232783168 (LWP 7604)]
[KCrash handler]
#6 0x0806be76 in TreeMapItem::parent (this=0x0)
at /home/bram/KDE/kde3/kdeaddons/konq-plugins/fsview/treemap.h:285
#7 0x08065fea in TreeMapItemList::compareItems (this=0xbfec04a8, item1=0x0,
item2=0x0)
at /home/bram/KDE/kde3/kdeaddons/konq-plugins/fsview/treemap.cpp:720
#8 0xb7281619 in QGList::operator== () from /usr/qt/3/lib/libqt-mt.so.3
#9 0x0806d498 in QPtrList<TreeMapItem>::operator== (this=0xbfec04a8,
list=@0xbfec0468) at /usr/qt/3/include/qptrlist.h:74
#10 0x08062e18 in TreeMapWidget::mousePressEvent (this=0xbfec03ac,
e=0xbfebff1c)
at /home/bram/KDE/kde3/kdeaddons/konq-plugins/fsview/treemap.cpp:1840
#11 0xb7004a63 in QWidget::event () from /usr/qt/3/lib/libqt-mt.so.3
#12 0xb6f6bca7 in QApplication::internalNotify ()
from /usr/qt/3/lib/libqt-mt.so.3
#13 0xb6f6ca88 in QApplication::notify () from /usr/qt/3/lib/libqt-mt.so.3
#14 0xb7725a84 in KApplication::notify (this=0xbfec055c, receiver=0xbfec03ac,
event=0xbfebff1c)
at /home/bram/KDE/kde3/kdelibs/kdecore/kapplication.cpp:550
#15 0xb6f0bfd2 in QETWidget::translateMouseEvent ()
from /usr/qt/3/lib/libqt-mt.so.3
#16 0xb6f0b8b0 in QApplication::x11ProcessEvent ()
from /usr/qt/3/lib/libqt-mt.so.3
#17 0xb6f1b761 in QEventLoop::processEvents () from /usr/qt/3/lib/libqt-mt.so.3
#18 0xb6f82831 in QEventLoop::enterLoop () from /usr/qt/3/lib/libqt-mt.so.3
#19 0xb6f826b6 in QEventLoop::exec () from /usr/qt/3/lib/libqt-mt.so.3
#20 0xb6f6b72f in QApplication::exec () from /usr/qt/3/lib/libqt-mt.so.3
#21 0x0805181e in main (argc=134673960, argv=0xffffffff)
at /home/bram/KDE/kde3/kdeaddons/konq-plugins/fsview/main.cpp:55

Molto meglio, vero? In questo backtrace sono presenti gli indirizzi di memoria, i file sorgenti, i numeri di riga e i parametri passati alle funzioni che hanno causato il problema. Ciò rende più facile per gli sviluppatori capire la causa del problema, in quanto sanno dove guardare.

{{note|È '''obbligatorio''' avere GDB installato per ottenere il backtrace di un crash. Nella sezione seguente è spiegato cos'è GDB e come installarlo.}}

===Ottenere un backtrace con GDB===

In alcuni casi non è possibile creare un backtrace con la finestra di dialogo dei crash di KDE. Ciò può essere dovuto da un'applicazione entrata in un loop infinito, o dal fatto che la finestra del crash non è apparsa per qualche motivo. In tali casi è possibile ottenere un backtrace con <tt>gdb</tt>, il [http://sourceware.org/gdb/ Debugger GNU]. GDB è disponibile pacchettizzato per tutte le distribuzioni più importanti.

Il richiamo di GDB dipende dalle situazioni. È possibile sia eseguire un'applicazione all'interno di gdb che collegare gdb ad un processo già in esecuzione. Quest'ultima situazione in particolare è utile quando un'applicazione è già entrata in un loop infinito. Cominciamo con la prima soluzione; per eseguire un'applicazione da gdb digitare sulla riga di comando:

$ gdb someKDEapp

Apparirà il prompt di GDB. Per avviare l'applicazione, al momento non ancora avviata, è necessario invocare il comando<tt>run</tt>:

(gdb) run

{{note|Alcune applicazioni di KDE (ad esempio JuK e KTorrent) contengono del codice speciale per assicurarsi che ci sia una sola istanza dell'applicazione avviata alla volta. Per queste applicazioni bisogna utilizzare il comando "run --nofork" al prompt di (gdb) invece di "run" perché altrimenti gdb proverebbe a debuggare il processo sbagliato. In caso di dubbio su quale usare è sufficiente provare ad avviare l'applicazione con l'opzione --nofork: se l'applicazione dice che è un'opzione sconosciuta è possibile rimuovere l'opzione --nofork.}}

Questo avvierà l'applicazione a cui siete abituati, e vi permetterà di lavorarci come fate solitamente (con la differenza che consumerà molta più memoria e potrebbe risultare molto più lenta). Ora va riprodotto il crash. Quando l'applicazione va in crash essa si chiuderà riportando al prompt di GDB. Ora è necessario invocare il comando 'backtrace':

(gdb) thread apply all backtrace

Ciò dovrebbe fornire una buona backtrace che può essere inserita nel Bugzilla di KDE.

In caso si voglia collegarsi ad un processo già esistente va invocato il seguente comando:

$ gdb someKDEapp pid

dove ''pid'' è il process ID del processo al quale ci si vuole collegare. Una volta collegati, quando il processo è in un ciclo infinito, dopo aver usato il comando 'backtrace' apparirà una traccia dell'esecuzione. È possibile utilizzare il comando 'continue' per lasciare l'applicazione eseguire nuovamente e premere Ctrl+C in gdb per poter inserire nuovamente dei comandi.

===Ottenere un backtrace con Valgrind===

Un altro strumento utile per creare backtrace di crash è [http://www.valgrind.org Valgrind]; esso non sostituisce GDB, ma piuttosto lo completa.

Quando si esegue un'applicazione in valgrind ogni pezzo di memoria letta o scritta dall'applicazione stessa viene controllato. Valgrind riporterà operazioni non valide in memoria nello standard output o in un file di log. Dato che la maggior parte dei crash sono dovuti a letture invalide in memoria, Valgrind può essere utile per tracciare dove succedono i problemi.

{{note|Valgrind consiste di vari tool per verificare o effettuare la profilazione di un'applicazione. In questo articolo useremo solo memcheck, il tool di default che viene chiamato all'esecuzione di valgrind.}}

Come GDB, Valgrind rende l'esecuzione delle applicazioni molto più lento e più esoso in termini di risorse.

Per avviare l'applicazione all'interno di valgrind:

$ valgrind --log-file=someKDEapp someKDEapp

Ora va riprodotto il crash. Appena avviene sia l'applicazione che valgrind termineranno. Ciò che rimane è un file con nome <tt>someKDEapp.pid</tt> dove ''pid'' sarà il process ID del processo valgrind. Il file potrebbe elencare più errori di quanti siano effettivamente causa del crash. Qui c'è un esempio della parte che causa il crash che corrisponde al backtrace GDB sopra:

==23292== Invalid read of size 4
==23292== at 0x806BD9E: TreeMapItem::parent() const (treemap.h:285)
==23292== by 0x8065FB9: TreeMapItemList::compareItems(void*, void*) (treemap.cpp:720)
==23292== by 0x50AC618: QGList::operator==(QGList const&) const (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== by 0x806D3BF: QPtrList<TreeMapItem>::operator==(QPtrList<TreeMapItem> const&) const (qptrlist.h:74)
==23292== by 0x8062DE7: TreeMapWidget::mousePressEvent(QMouseEvent*) (treemap.cpp:1840)
==23292== by 0x4E2FA62: QWidget::event(QEvent*) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== by 0x4D96CA6: QApplication::internalNotify(QObject*, QEvent*) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== by 0x4D97A87: QApplication::notify(QObject*, QEvent*) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== by 0x4809AC3: KApplication::notify(QObject*, QEvent*) (kapplication.cpp:550)
==23292== by 0x4D36FD1: QETWidget::translateMouseEvent(_XEvent const*) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== by 0x4D368AF: QApplication::x11ProcessEvent(_XEvent*) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== by 0x4D46760: QEventLoop::processEvents(unsigned) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== Address 0x2C is not stack'd, malloc'd or (recently) free'd

Per essere sicuro allega alla segnalazione del bug l'intero file log fornito da valgrind.

User:Panda84/Development/Tutorials/Debugging/How to create useful crash reports (it)

2010-06-05T10:39:21Z

#REDIRECT [[Development/Tutorials/Debugging/How to create useful crash reports (it)]]

Development/Tutorials/Debugging/How to create useful crash reports (it)

2010-06-05T10:37:42Z

Panda84: Fix sezione GDB

{{Template:I18n/Language Navigation Bar|Development/Tutorials/Debugging/How to create useful crash reports}}

== Introduzione ==

Questo documento descrive come riprodurre un backtrace (ovvero una "traccia dell'esecuzione") di applicazioni KDE che vanno in crash. Inizialmente vengono fornite alcune informazioni generali; nel seguito vengono descritte le procedure per ottenere i pacchetti KDE per varie distribuzioni utili a ottenere i backtrace. Queste parti dovrebbero essere sufficienti per la maggior parte della gente. Ci sono alcune sezioni addizionali su come creare backtrace con il GNU Debugger e con Valgrind, che possono essere utili in alcuni casi.

== Come creare segnalazioni di crash utili ==

Una buona segnalazione di bug nel [http://bugs.kde.org Bugzilla] consiste di due parti: una '''descrizione''' di come riprodurre il crash ed un '''backtrace''' del crash stesso. Se manca uno di questi elementi risulta molto più difficile, se non impossibile, per gli sviluppatori affrontare il problema.

Una descrizione deve consistere di qualcosa più di un solo "si è piantato". È necessario cercare di descrivere qualsiasi cosa venga fatta prima del crash. È stato cliccato su un pulsante, aperto un particolare sito o file che ha causato il problema? Quel piccolo dettaglio che potrebbe sembrare inutile all'utente potrebbe risultare utile allo sviluppatore, quindi è sempre il caso di annotarlo nella segnalazione.

Un articolo approfondito su come scrivere delle buone descrizioni di bug e segnalazioni è disponibile a [http://www.chiark.greenend.org.uk/~sgtatham/bugs.html questo indirizzo], è caldamente consigliato leggerlo prima di effettuare delle segnalazioni.

Il backtrace di un crash non va allegato alla segnalazione; va semplicemente incollato in coda al testo della segnalazione stessa. In questo modo è molto più semplice per gli sviluppatori individuare segnalazioni duplicate dello stesso bug, in quanto la ricerca non avviene anche sul testo degli allegati.

Se si incolla un backtrace in una segnalazione assicurarsi di rimuovere tutte le righe, eccetto un paio, del tipo:

(no debugging symbols found)

dal backtrace, in quanto lo rendono più difficile da leggere.

Sebbene incollare backtrace direttamente sia preferibile rispetto ad aggiungere un allegato, non vanno incollate altre cose come log (valgrind, strace o output del terminale) o esempi di dati (email, file HTML e così via); per queste cose vanno usati gli allegati.

=== Backtrace ===

I backtrace sono essenziali. Possono sembrare senza significato per i non addetti, ma in realtà possono contenere una gran quantità di informazioni utili. Un backtrace descrive quali funzioni sono state chiamate prima del crash, in modo che gli sviluppatori possano tracciare in quale metodo è partito il problema. Ottenere buoni backtrace ha uno svantaggio: [[Development/Tutorials/Debugging/Debugging_symbols|le librerie e gli eseguibili occupano molto più spazio rispetto alla versione ottimizzata]]. È per questo motivo che molte distribuzioni scelgono di installare file senza simboli di debugging, '''cosa che causa la creazione di backtrace inutili''' come questo:

(no debugging symbols found)
Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread -1233848624 (LWP 12212)]
[New Thread -1255081072 (LWP 12820)]
[New Thread -1240921200 (LWP 12819)]
[New Thread -1266680944 (LWP 12818)]
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
0xffffe410 in __kernel_vsyscall ()
#0 0xffffe410 in __kernel_vsyscall ()
#1 0xb6a1210b in ?? () from /lib/tls/i686/cmov/libpthread.so.0
#2 0xb6a85afe in ?? () from /usr/lib/libX11.so.6
#3 0x00000003 in ?? ()
#4 0x082149c0 in ?? ()
#5 0x00003ffc in ?? ()
#6 0x00000000 in ?? ()

Per fortuna non c'è da preoccuparsi, con alcune modifiche è possibile creare backtrace con tutte le informazioni necessarie per le applicazioni KDE.

=== Preparare i pacchetti KDE ===

Se la distribuzione in uso ha pacchetti predisposti per il debugging è necessario installarli.

È facile vedere quali pacchetti di debug manchino guardando il backtrace. Prendiamo in considerazione la seguente linea di una backtrace:

#6 0xb7975bdc in ?? () from /usr/lib/libkmailprivate.so.4

Il simbolo <tt>??</tt> indica che la libreria <tt>libkmailprivate.so.4</tt> è priva di informazioni di debug, che potrebbero essere disponibili in pacchetti di debug separati. In questo caso, è facile capire che è necessario installare i pacchetti di debug per KMail per ottenere un backtrace migliore.

Alcune volte, c'è bisogno di installare più di un pacchetto di debug per ottenere un buon backtrace. Ciò dipende da come le distribuzioni suddividono i pacchetti. Per esempio, per alcune distribuzioni è sufficiente installare il pacchetto per <tt>kdepim</tt> per avere sufficienti informazioni riguardo un crash in KMail, in altre distribuzioni c'è un pacchetto di debug aggiuntivo per KMail.

Qui ci sono le istruzioni che spiegano come ottenere i pacchetti di debug per alcune distribuzioni:

*'''Debian''' - Debian offre pacchetti <tt>-dbg</tt> per creare facilmente backtrace utili. Basta installare il corrispondente pacchetto <tt>-dbg</tt>. ad esempio <tt>kdepim-dbg</tt> per i crash di KMail. Le dipendenze di -dbg assicurano di ottenere anche gli altri pacchetti necessari (kdelibs-dbg, gdb, e così via).
*'''FreeBSD ports''' - Fare riferimento alla pagina [http://freebsd.kde.org/faq.php#AKDEapplicationcrashedandIwanttofileabugreportathttpbugskdeorgbutthebacktraceintheKDECrashManagerisuselessWhatcanIdo delle FAQ di KDE su FreeBSD].
*'''Gentoo''' - Gentoo ha [http://www.gentoo.org/proj/en/qa/backtraces.xml una guida] che descrive come procedere.
*'''Mandriva''' - A partire da Mandriva 2007.0 in su ci sono pacchetti addizionali per tutto KDE. È sufficiente installare il corrispondente pacchetto <tt>-debug</tt>, come <tt>kdebase-debug</tt> e <tt>kdemultimedia-debug</tt>. Quasi certamente va installato <tt>kdelibs-debug</tt> in ogni caso.
** Nota: i pacchetti <tt>-debug</tt> sono in repository separati. Ad esempio, per tutti i pacchetti in <tt>main</tt>, si possono trovare i pacchetti di debug nel repository <tt>debug_main</tt>.
*'''Kubuntu/Ubuntu''' - La famiglia di distribuzioni Ubuntu rende le cose abbastanza facili. Ogni modulo ufficiale di KDE ha un pacchetto aggiuntivo nei repository con il suffisso <tt>-dbg</tt>. È importante installare sempre <tt>kdelibs5-dbg</tt>, in quanto tutte le applicazioni KDE usano kdelibs (kdelibs-dbg per applicazioni KDE 3). Oltre a ciò è necessario installare il pacchetto -dbg anche per l'applicazione che è andata in crash. Per esempio se si è piantato KOrganizer è necessario installare anche <tt>kdepim-dbg</tt>. Se il programma non fa parte di un modulo ufficiale di KDE e non ha un apposito pacchetto -dbg, è possibile installare il pacchetto -dbgsym dal repository in questa [https://wiki.kubuntu.org/DebuggingProgramCrash pagina sul debugging dei programmi].
** Durante il ciclo di sviluppo di Ubuntu il gestore di crash Apport è attivo e si preoccuperà di riportare i crash a launchpad.net e creare il backtrace per te. Se si desidera utilizzare il gestore dei crash di KDE è possibile disabilitarlo nel file /etc/defaults/apport
** A partire da Lucid Lynx (10.04) Kubuntu inoltrerà tutti i bug che non sono peculiari della distribuzione al sistema di gestione di KDE; Apport è ora disabilitato in modo da utilizzare DrKonqui come gestore predefinito dei crash.
*'''openSUSE''' - È necessario solo installare i pacchetti <tt>-debuginfo</tt>, ad esempio: <tt>kdepimlibs4-debuginfo</tt>. È possibile trovare questi pacchetti nei [http://en.opensuse.org/KDE/Repositories repository KDE]. C'è anche una [http://en.opensuse.org/Bugs:An_application_crashed pagina dedicata al debugging in openSUSE].
*'''Fedora''' - In Fedora è sufficiente utilizzare i seguenti comandi:
*# <tt>yum provides "/usr/lib/libkmailprivate.so.4"</tt> per trovare quale pacchetto fornisce quel file;
*# <tt>debuginfo-install kdepim</tt> da utente root per installare i pacchetti di debug per quel pacchetto (dipendenze incluse).
*: Una guida completa e dettagliata per Fedora è disponibile in [http://fedoraproject.org/wiki/StackTraces questo documento] che descrive come procedere. Fedora utilizza un repository debuginfo separato che va abilitato. Si consiglia anche di utilizzare il plugin yum <tt>auto-update-debug-info</tt> per tenere aggiornati i pacchetti debuginfo.

Nel raro caso in cui la distribuzione non abbia pacchetti contenenti i simboli di debug per KDE, è necessario compilare KDE dai sorgenti:

* Nel caso di KDE 3, al passo di configure, è necessario passare il parametro <tt>--enable-debug=full</tt> al fine di creare i simboli di debug nei file risultanti.
* Nel caso di KDE 4, al passo di cmake, è necessario passare il parametro <tt>-DCMAKE_BUILD_TYPE=debugfull</tt>. Se si vuole passare opzioni personalizzate a CXXFLAGS, utilizzare <tt>-DCMAKE_BUILD_TYPE=None CMAKE_CXX_FLAGS="-O0 -g"</tt>. È possibile cambiare le opzioni CMAKE_CXX_FLAGS in base alle proprie necessità.

Dopodiché è sufficiente dare <tt>make</tt> e <tt>make install</tt> come al solito.

===Crash!===

Ora che sono state reperite le informazioni per rendere utile la traccia dell'esecuzione va riprodotto il crash nell'applicazione. La finestra di dialogo di KDE apparirà qualche istante dopo al crash dell'applicazione.

[[Image:Kde-crash-handler.png|center|300px|La finestra di dialogo dei crash di KDE]]

Ora la generazione del backtrace dovrebbe risultare molto più completa, ad esempio:

Using host libthread_db library "/lib/libthread_db.so.1".
[Thread debugging using libthread_db enabled]
[New Thread -1232783168 (LWP 7604)]
[KCrash handler]
#6 0x0806be76 in TreeMapItem::parent (this=0x0)
at /home/bram/KDE/kde3/kdeaddons/konq-plugins/fsview/treemap.h:285
#7 0x08065fea in TreeMapItemList::compareItems (this=0xbfec04a8, item1=0x0,
item2=0x0)
at /home/bram/KDE/kde3/kdeaddons/konq-plugins/fsview/treemap.cpp:720
#8 0xb7281619 in QGList::operator== () from /usr/qt/3/lib/libqt-mt.so.3
#9 0x0806d498 in QPtrList<TreeMapItem>::operator== (this=0xbfec04a8,
list=@0xbfec0468) at /usr/qt/3/include/qptrlist.h:74
#10 0x08062e18 in TreeMapWidget::mousePressEvent (this=0xbfec03ac,
e=0xbfebff1c)
at /home/bram/KDE/kde3/kdeaddons/konq-plugins/fsview/treemap.cpp:1840
#11 0xb7004a63 in QWidget::event () from /usr/qt/3/lib/libqt-mt.so.3
#12 0xb6f6bca7 in QApplication::internalNotify ()
from /usr/qt/3/lib/libqt-mt.so.3
#13 0xb6f6ca88 in QApplication::notify () from /usr/qt/3/lib/libqt-mt.so.3
#14 0xb7725a84 in KApplication::notify (this=0xbfec055c, receiver=0xbfec03ac,
event=0xbfebff1c)
at /home/bram/KDE/kde3/kdelibs/kdecore/kapplication.cpp:550
#15 0xb6f0bfd2 in QETWidget::translateMouseEvent ()
from /usr/qt/3/lib/libqt-mt.so.3
#16 0xb6f0b8b0 in QApplication::x11ProcessEvent ()
from /usr/qt/3/lib/libqt-mt.so.3
#17 0xb6f1b761 in QEventLoop::processEvents () from /usr/qt/3/lib/libqt-mt.so.3
#18 0xb6f82831 in QEventLoop::enterLoop () from /usr/qt/3/lib/libqt-mt.so.3
#19 0xb6f826b6 in QEventLoop::exec () from /usr/qt/3/lib/libqt-mt.so.3
#20 0xb6f6b72f in QApplication::exec () from /usr/qt/3/lib/libqt-mt.so.3
#21 0x0805181e in main (argc=134673960, argv=0xffffffff)
at /home/bram/KDE/kde3/kdeaddons/konq-plugins/fsview/main.cpp:55

Molto meglio, vero? In questo backtrace sono presenti gli indirizzi di memoria, i file sorgenti, i numeri di riga e i parametri passati alle funzioni che hanno causato il problema. Ciò rende più facile per gli sviluppatori capire la causa del problema, in quanto sanno dove guardare.

{{note|È '''obbligatorio''' avere GDB installato per ottenere il backtrace di un crash. Nella sezione seguente è spiegato cos'è GDB e come installarlo.}}

===Ottenere un backtrace con GDB===

In alcuni casi non è possibile creare un backtrace con la finestra di dialogo dei crash di KDE. Ciò può essere dovuto da un'applicazione entrata in un loop infinito, o dal fatto che la finestra del crash non è apparsa per qualche motivo. In tali casi è possibile ottenere un backtrace con <tt>gdb</tt>, il [http://sourceware.org/gdb/ Debugger GNU]. GDB è disponibile pacchettizzato per tutte le distribuzioni più importanti.

Il richiamo di GDB dipende dalle situazioni. È possibile sia eseguire un'applicazione all'interno di gdb che collegare gdb ad un processo già in esecuzione. Quest'ultima situazione in particolare è utile quando un'applicazione è già entrata in un loop infinito. Cominciamo con la prima soluzione; per eseguire un'applicazione da gdb digitare sulla riga di comando:

$ gdb someKDEapp

Apparirà il prompt di GDB. Per avviare l'applicazione, al momento non ancora avviata, è necessario invocare il comando<tt>run</tt>:

(gdb) run

{{note|Alcune applicazioni di KDE (ad esempio JuK e KTorrent) contengono del codice speciale per assicurarsi che ci sia una sola istanza dell'applicazione avviata alla volta. Per queste applicazioni bisogna utilizzare il comando "run --nofork" al prompt di (gdb) invece di "run" perché altrimenti gdb proverebbe a debuggare il processo sbagliato. In caso di dubbio su quale usare è sufficiente provare ad avviare l'applicazione con l'opzione --nofork: se l'applicazione dice che è un'opzione sconosciuta è possibile rimuovere l'opzione --nofork.}}

Questo avvierà l'applicazione a cui siete abituati, e vi permetterà di lavorarci come fate solitamente (con la differenza che consumerà molta più memoria e potrebbe risultare molto più lenta). Ora va riprodotto il crash. Quando l'applicazione va in crash essa si chiuderà riportando al prompt di GDB. Ora è necessario invocare il comando 'backtrace':

(gdb) thread apply all backtrace

Ciò dovrebbe fornire una buona backtrace che può essere inserita nel Bugzilla di KDE.

In caso si voglia collegarsi ad un processo già esistente va invocato il seguente comando:

$ gdb someKDEapp pid

dove ''pid'' è il process ID del processo al quale ci si vuole collegare. Una volta collegati, quando il processo è in un ciclo infinito, dopo aver usato il comando 'backtrace' apparirà una traccia dell'esecuzione. È possibile utilizzare il comando 'continue' per lasciare l'applicazione eseguire nuovamente e premere Ctrl+C in gdb per poter inserire nuovamente dei comandi.

===Ottenere un backtrace con Valgrind===

Un altro strumento utile per creare backtrace di crash è [http://www.valgrind.org Valgrind]; esso non sostituisce GDB, ma piuttosto lo completa.

Quando si esegue un'applicazione in valgrind ogni pezzo di memoria letta o scritta dall'applicazione stessa viene controllato. Valgrind riporterà operazioni non valide in memoria nello standard output o in un file di log. Dato che la maggior parte dei crash sono dovuti a letture invalide in memoria, Valgrind può essere utile per tracciare dove succedono i problemi.

{{note|Valgrind consiste di vari tool per verificare o effettuare la profilazione di un'applicazione. In questo articolo useremo solo memcheck, il tool di default che viene chiamato all'esecuzione di valgrind.}}

Come GDB, Valgrind rende l'esecuzione delle applicazioni molto più lento e più esoso in termini di risorse.

Per avviare l'applicazione all'interno di valgrind:

$ valgrind --log-file=someKDEapp someKDEapp

Ora va riprodotto il crash. Appena avviene sia l'applicazione che valgrind termineranno. Ciò che rimane è un file con nome <tt>someKDEapp.pid</tt> dove ''pid'' sarà il process ID del processo valgrind. Il file potrebbe elencare più errori di quanti siano effettivamente causa del crash. Qui c'è un esempio della parte che causa il crash che corrisponde al backtrace GDB sopra:

==23292== Invalid read of size 4
==23292== at 0x806BD9E: TreeMapItem::parent() const (treemap.h:285)
==23292== by 0x8065FB9: TreeMapItemList::compareItems(void*, void*) (treemap.cpp:720)
==23292== by 0x50AC618: QGList::operator==(QGList const&) const (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== by 0x806D3BF: QPtrList<TreeMapItem>::operator==(QPtrList<TreeMapItem> const&) const (qptrlist.h:74)
==23292== by 0x8062DE7: TreeMapWidget::mousePressEvent(QMouseEvent*) (treemap.cpp:1840)
==23292== by 0x4E2FA62: QWidget::event(QEvent*) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== by 0x4D96CA6: QApplication::internalNotify(QObject*, QEvent*) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== by 0x4D97A87: QApplication::notify(QObject*, QEvent*) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== by 0x4809AC3: KApplication::notify(QObject*, QEvent*) (kapplication.cpp:550)
==23292== by 0x4D36FD1: QETWidget::translateMouseEvent(_XEvent const*) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== by 0x4D368AF: QApplication::x11ProcessEvent(_XEvent*) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== by 0x4D46760: QEventLoop::processEvents(unsigned) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== Address 0x2C is not stack'd, malloc'd or (recently) free'd

Per essere sicuro allega alla segnalazione del bug l'intero file log fornito da valgrind.

Development/Tutorials/Debugging/How to create useful crash reports (it)

2010-06-05T10:29:13Z

Panda84: Fix nella sezione pacchetti per le distribuzioni.

{{Template:I18n/Language Navigation Bar|Development/Tutorials/Debugging/How to create useful crash reports}}

== Introduzione ==

Questo documento descrive come riprodurre un backtrace (ovvero una "traccia dell'esecuzione") di applicazioni KDE che vanno in crash. Inizialmente vengono fornite alcune informazioni generali; nel seguito vengono descritte le procedure per ottenere i pacchetti KDE per varie distribuzioni utili a ottenere i backtrace. Queste parti dovrebbero essere sufficienti per la maggior parte della gente. Ci sono alcune sezioni addizionali su come creare backtrace con il GNU Debugger e con Valgrind, che possono essere utili in alcuni casi.

== Come creare segnalazioni di crash utili ==

Una buona segnalazione di bug nel [http://bugs.kde.org Bugzilla] consiste di due parti: una '''descrizione''' di come riprodurre il crash ed un '''backtrace''' del crash stesso. Se manca uno di questi elementi risulta molto più difficile, se non impossibile, per gli sviluppatori affrontare il problema.

Una descrizione deve consistere di qualcosa più di un solo "si è piantato". È necessario cercare di descrivere qualsiasi cosa venga fatta prima del crash. È stato cliccato su un pulsante, aperto un particolare sito o file che ha causato il problema? Quel piccolo dettaglio che potrebbe sembrare inutile all'utente potrebbe risultare utile allo sviluppatore, quindi è sempre il caso di annotarlo nella segnalazione.

Un articolo approfondito su come scrivere delle buone descrizioni di bug e segnalazioni è disponibile a [http://www.chiark.greenend.org.uk/~sgtatham/bugs.html questo indirizzo], è caldamente consigliato leggerlo prima di effettuare delle segnalazioni.

Il backtrace di un crash non va allegato alla segnalazione; va semplicemente incollato in coda al testo della segnalazione stessa. In questo modo è molto più semplice per gli sviluppatori individuare segnalazioni duplicate dello stesso bug, in quanto la ricerca non avviene anche sul testo degli allegati.

Se si incolla un backtrace in una segnalazione assicurarsi di rimuovere tutte le righe, eccetto un paio, del tipo:

(no debugging symbols found)

dal backtrace, in quanto lo rendono più difficile da leggere.

Sebbene incollare backtrace direttamente sia preferibile rispetto ad aggiungere un allegato, non vanno incollate altre cose come log (valgrind, strace o output del terminale) o esempi di dati (email, file HTML e così via); per queste cose vanno usati gli allegati.

=== Backtrace ===

I backtrace sono essenziali. Possono sembrare senza significato per i non addetti, ma in realtà possono contenere una gran quantità di informazioni utili. Un backtrace descrive quali funzioni sono state chiamate prima del crash, in modo che gli sviluppatori possano tracciare in quale metodo è partito il problema. Ottenere buoni backtrace ha uno svantaggio: [[Development/Tutorials/Debugging/Debugging_symbols|le librerie e gli eseguibili occupano molto più spazio rispetto alla versione ottimizzata]]. È per questo motivo che molte distribuzioni scelgono di installare file senza simboli di debugging, '''cosa che causa la creazione di backtrace inutili''' come questo:

(no debugging symbols found)
Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread -1233848624 (LWP 12212)]
[New Thread -1255081072 (LWP 12820)]
[New Thread -1240921200 (LWP 12819)]
[New Thread -1266680944 (LWP 12818)]
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
0xffffe410 in __kernel_vsyscall ()
#0 0xffffe410 in __kernel_vsyscall ()
#1 0xb6a1210b in ?? () from /lib/tls/i686/cmov/libpthread.so.0
#2 0xb6a85afe in ?? () from /usr/lib/libX11.so.6
#3 0x00000003 in ?? ()
#4 0x082149c0 in ?? ()
#5 0x00003ffc in ?? ()
#6 0x00000000 in ?? ()

Per fortuna non c'è da preoccuparsi, con alcune modifiche è possibile creare backtrace con tutte le informazioni necessarie per le applicazioni KDE.

=== Preparare i pacchetti KDE ===

Se la distribuzione in uso ha pacchetti predisposti per il debugging è necessario installarli.

È facile vedere quali pacchetti di debug manchino guardando il backtrace. Prendiamo in considerazione la seguente linea di una backtrace:

#6 0xb7975bdc in ?? () from /usr/lib/libkmailprivate.so.4

Il simbolo <tt>??</tt> indica che la libreria <tt>libkmailprivate.so.4</tt> è priva di informazioni di debug, che potrebbero essere disponibili in pacchetti di debug separati. In questo caso, è facile capire che è necessario installare i pacchetti di debug per KMail per ottenere un backtrace migliore.

Alcune volte, c'è bisogno di installare più di un pacchetto di debug per ottenere un buon backtrace. Ciò dipende da come le distribuzioni suddividono i pacchetti. Per esempio, per alcune distribuzioni è sufficiente installare il pacchetto per <tt>kdepim</tt> per avere sufficienti informazioni riguardo un crash in KMail, in altre distribuzioni c'è un pacchetto di debug aggiuntivo per KMail.

Qui ci sono le istruzioni che spiegano come ottenere i pacchetti di debug per alcune distribuzioni:

*'''Debian''' - Debian offre pacchetti <tt>-dbg</tt> per creare facilmente backtrace utili. Basta installare il corrispondente pacchetto <tt>-dbg</tt>. ad esempio <tt>kdepim-dbg</tt> per i crash di KMail. Le dipendenze di -dbg assicurano di ottenere anche gli altri pacchetti necessari (kdelibs-dbg, gdb, e così via).
*'''FreeBSD ports''' - Fare riferimento alla pagina [http://freebsd.kde.org/faq.php#AKDEapplicationcrashedandIwanttofileabugreportathttpbugskdeorgbutthebacktraceintheKDECrashManagerisuselessWhatcanIdo delle FAQ di KDE su FreeBSD].
*'''Gentoo''' - Gentoo ha [http://www.gentoo.org/proj/en/qa/backtraces.xml una guida] che descrive come procedere.
*'''Mandriva''' - A partire da Mandriva 2007.0 in su ci sono pacchetti addizionali per tutto KDE. È sufficiente installare il corrispondente pacchetto <tt>-debug</tt>, come <tt>kdebase-debug</tt> e <tt>kdemultimedia-debug</tt>. Quasi certamente va installato <tt>kdelibs-debug</tt> in ogni caso.
** Nota: i pacchetti <tt>-debug</tt> sono in repository separati. Ad esempio, per tutti i pacchetti in <tt>main</tt>, si possono trovare i pacchetti di debug nel repository <tt>debug_main</tt>.
*'''Kubuntu/Ubuntu''' - La famiglia di distribuzioni Ubuntu rende le cose abbastanza facili. Ogni modulo ufficiale di KDE ha un pacchetto aggiuntivo nei repository con il suffisso <tt>-dbg</tt>. È importante installare sempre <tt>kdelibs5-dbg</tt>, in quanto tutte le applicazioni KDE usano kdelibs (kdelibs-dbg per applicazioni KDE 3). Oltre a ciò è necessario installare il pacchetto -dbg anche per l'applicazione che è andata in crash. Per esempio se si è piantato KOrganizer è necessario installare anche <tt>kdepim-dbg</tt>. Se il programma non fa parte di un modulo ufficiale di KDE e non ha un apposito pacchetto -dbg, è possibile installare il pacchetto -dbgsym dal repository in questa [https://wiki.kubuntu.org/DebuggingProgramCrash pagina sul debugging dei programmi].
** Durante il ciclo di sviluppo di Ubuntu il gestore di crash Apport è attivo e si preoccuperà di riportare i crash a launchpad.net e creare il backtrace per te. Se si desidera utilizzare il gestore dei crash di KDE è possibile disabilitarlo nel file /etc/defaults/apport
** A partire da Lucid Lynx (10.04) Kubuntu inoltrerà tutti i bug che non sono peculiari della distribuzione al sistema di gestione di KDE; Apport è ora disabilitato in modo da utilizzare DrKonqui come gestore predefinito dei crash.
*'''openSUSE''' - È necessario solo installare i pacchetti <tt>-debuginfo</tt>, ad esempio: <tt>kdepimlibs4-debuginfo</tt>. È possibile trovare questi pacchetti nei [http://en.opensuse.org/KDE/Repositories repository KDE]. C'è anche una [http://en.opensuse.org/Bugs:An_application_crashed pagina dedicata al debugging in openSUSE].
*'''Fedora''' - In Fedora è sufficiente utilizzare i seguenti comandi:
*# <tt>yum provides "/usr/lib/libkmailprivate.so.4"</tt> per trovare quale pacchetto fornisce quel file;
*# <tt>debuginfo-install kdepim</tt> da utente root per installare i pacchetti di debug per quel pacchetto (dipendenze incluse).
*: Una guida completa e dettagliata per Fedora è disponibile in [http://fedoraproject.org/wiki/StackTraces questo documento] che descrive come procedere. Fedora utilizza un repository debuginfo separato che va abilitato. Si consiglia anche di utilizzare il plugin yum <tt>auto-update-debug-info</tt> per tenere aggiornati i pacchetti debuginfo.

Nel raro caso in cui la distribuzione non abbia pacchetti contenenti i simboli di debug per KDE, è necessario compilare KDE dai sorgenti:

* Nel caso di KDE 3, al passo di configure, è necessario passare il parametro <tt>--enable-debug=full</tt> al fine di creare i simboli di debug nei file risultanti.
* Nel caso di KDE 4, al passo di cmake, è necessario passare il parametro <tt>-DCMAKE_BUILD_TYPE=debugfull</tt>. Se si vuole passare opzioni personalizzate a CXXFLAGS, utilizzare <tt>-DCMAKE_BUILD_TYPE=None CMAKE_CXX_FLAGS="-O0 -g"</tt>. È possibile cambiare le opzioni CMAKE_CXX_FLAGS in base alle proprie necessità.

Dopodiché è sufficiente dare <tt>make</tt> e <tt>make install</tt> come al solito.

===Crash!===

Ora che sono state reperite le informazioni per rendere utile la traccia dell'esecuzione va riprodotto il crash nell'applicazione. La finestra di dialogo di KDE apparirà qualche istante dopo al crash dell'applicazione.

[[Image:Kde-crash-handler.png|center|300px|La finestra di dialogo dei crash di KDE]]

Ora la generazione del backtrace dovrebbe risultare molto più completa, ad esempio:

Using host libthread_db library "/lib/libthread_db.so.1".
[Thread debugging using libthread_db enabled]
[New Thread -1232783168 (LWP 7604)]
[KCrash handler]
#6 0x0806be76 in TreeMapItem::parent (this=0x0)
at /home/bram/KDE/kde3/kdeaddons/konq-plugins/fsview/treemap.h:285
#7 0x08065fea in TreeMapItemList::compareItems (this=0xbfec04a8, item1=0x0,
item2=0x0)
at /home/bram/KDE/kde3/kdeaddons/konq-plugins/fsview/treemap.cpp:720
#8 0xb7281619 in QGList::operator== () from /usr/qt/3/lib/libqt-mt.so.3
#9 0x0806d498 in QPtrList<TreeMapItem>::operator== (this=0xbfec04a8,
list=@0xbfec0468) at /usr/qt/3/include/qptrlist.h:74
#10 0x08062e18 in TreeMapWidget::mousePressEvent (this=0xbfec03ac,
e=0xbfebff1c)
at /home/bram/KDE/kde3/kdeaddons/konq-plugins/fsview/treemap.cpp:1840
#11 0xb7004a63 in QWidget::event () from /usr/qt/3/lib/libqt-mt.so.3
#12 0xb6f6bca7 in QApplication::internalNotify ()
from /usr/qt/3/lib/libqt-mt.so.3
#13 0xb6f6ca88 in QApplication::notify () from /usr/qt/3/lib/libqt-mt.so.3
#14 0xb7725a84 in KApplication::notify (this=0xbfec055c, receiver=0xbfec03ac,
event=0xbfebff1c)
at /home/bram/KDE/kde3/kdelibs/kdecore/kapplication.cpp:550
#15 0xb6f0bfd2 in QETWidget::translateMouseEvent ()
from /usr/qt/3/lib/libqt-mt.so.3
#16 0xb6f0b8b0 in QApplication::x11ProcessEvent ()
from /usr/qt/3/lib/libqt-mt.so.3
#17 0xb6f1b761 in QEventLoop::processEvents () from /usr/qt/3/lib/libqt-mt.so.3
#18 0xb6f82831 in QEventLoop::enterLoop () from /usr/qt/3/lib/libqt-mt.so.3
#19 0xb6f826b6 in QEventLoop::exec () from /usr/qt/3/lib/libqt-mt.so.3
#20 0xb6f6b72f in QApplication::exec () from /usr/qt/3/lib/libqt-mt.so.3
#21 0x0805181e in main (argc=134673960, argv=0xffffffff)
at /home/bram/KDE/kde3/kdeaddons/konq-plugins/fsview/main.cpp:55

Molto meglio, vero? In questo backtrace sono presenti gli indirizzi di memoria, i file sorgenti, i numeri di riga e i parametri passati alle funzioni che hanno causato il problema. Ciò rende più facile per gli sviluppatori capire la causa del problema, in quanto sa dove guardare.

{{note|È '''obbligatorio''' avere GDB installato per ottenere il backtrace di un crash. Nella sezione seguente è spiegato cos'è GDB e come installarlo.}}

===Ottenere un backtrace con GDB===

In alcuni casi non è possibile creare un backtrace con la finestra di dialogo dei crash di KDE. Ciò può essere dovuto da un'applicazione entrata in un loop infinito, o dal fatto che la finestra del crash non è apparsa per qualche motivo. In tali casi è possibile ottenere un backtrace con <tt>gdb</tt>, il [http://sourceware.org/gdb/ Debugger GNU]. GDB è disponibile pacchettizzato per tutte le distribuzioni più importanti.

Il richiamo di GDB dipende dalle situazioni. È possibile sia eseguire un'applicazione all'interno di gdb che collegare gdb ad un processo già in esecuzione. Quest'ultima situazione in particolare è utile quando un'applicazione è già entrata in un loop infinito. Cominciamo con la prima soluzione; per eseguire un'applicazione da gdb digitare sulla riga di comando:

$ gdb someKDEapp

Apparirà il prompt di GDB. Per avviare l'applicazione, al momento non ancora avviata, è necessario invocare il comando<tt>run</tt>:

(gdb) run

{{note|Alcune applicazioni di KDE (ad esempio JuK e KTorrent) contengono del codice speciale per assicurarsi che ci sia una sola istanza dell'applicazione avviata alla volta. Per queste applicazioni è bisogna utilizzare il comando "run --nofork" al prompt di (gdb) invece di "run" perché altrimenti gdb proverebbe a debuggare il processo sbagliato. In caso di dubbio su quale usare è sufficiente provare ad avviare l'applicazione con l'opzione --nofork: se l'applicazione dice che è un'opzione sconosciuta è possibile rimuovere l'opzione --nofork.}}

Questo avvierà l'applicazione a cui siete abituati, e vi permetterà di lavorarci come fate solitamente (con la differenza che consumerà molta più memoria e potrebbe risultare molto più lenta). Ora va riprodotto il crash. Quando l'applicazione va in crash essa si chiuderà riportando al prompt di GDB. Ora è necessario invocare il comando 'backtrace':

(gdb) thread apply all backtrace

Ciò dovrebbe fornire una buona backtrace che può essere inserita nel Bugzilla di KDE.

In caso si voglia collegarsi ad un processo già esistente va invocato il seguente comando:

$ gdb someKDEapp pid

dove ''pid'' è il process ID del processo al quale ci si vuole collegare. Una volta collegati, quando il processo è in un ciclo infinito, dopo aver usato il comando 'backtrace' apparirà una traccia dell'esecuzione. È possibile utilizzare il comando 'continue' per lasciare l'applicazione eseguire nuovamente e premere Ctrl+C in gdb per poter inserire nuovamente dei comandi.

===Ottenere un backtrace con Valgrind===

Un altro strumento utile per creare backtrace di crash è [http://www.valgrind.org Valgrind]; esso non sostituisce GDB, ma piuttosto lo completa.

Quando si esegue un'applicazione in valgrind ogni pezzo di memoria letta o scritta dall'applicazione stessa viene controllato. Valgrind riporterà operazioni non valide in memoria nello standard output o in un file di log. Dato che la maggior parte dei crash sono dovuti a letture invalide in memoria, Valgrind può essere utile per tracciare dove succedono i problemi.

{{note|Valgrind consiste di vari tool per verificare o effettuare la profilazione di un'applicazione. In questo articolo useremo solo memcheck, il tool di default che viene chiamato all'esecuzione di valgrind.}}

Come GDB, Valgrind rende l'esecuzione delle applicazioni molto più lento e più esoso in termini di risorse.

Per avviare l'applicazione all'interno di valgrind:

$ valgrind --log-file=someKDEapp someKDEapp

Ora va riprodotto il crash. Appena avviene sia l'applicazione che valgrind termineranno. Ciò che rimane è un file con nome <tt>someKDEapp.pid</tt> dove ''pid'' sarà il process ID del processo valgrind. Il file potrebbe elencare più errori di quanti siano effettivamente causa del crash. Qui c'è un esempio della parte che causa il crash che corrisponde al backtrace GDB sopra:

==23292== Invalid read of size 4
==23292== at 0x806BD9E: TreeMapItem::parent() const (treemap.h:285)
==23292== by 0x8065FB9: TreeMapItemList::compareItems(void*, void*) (treemap.cpp:720)
==23292== by 0x50AC618: QGList::operator==(QGList const&) const (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== by 0x806D3BF: QPtrList<TreeMapItem>::operator==(QPtrList<TreeMapItem> const&) const (qptrlist.h:74)
==23292== by 0x8062DE7: TreeMapWidget::mousePressEvent(QMouseEvent*) (treemap.cpp:1840)
==23292== by 0x4E2FA62: QWidget::event(QEvent*) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== by 0x4D96CA6: QApplication::internalNotify(QObject*, QEvent*) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== by 0x4D97A87: QApplication::notify(QObject*, QEvent*) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== by 0x4809AC3: KApplication::notify(QObject*, QEvent*) (kapplication.cpp:550)
==23292== by 0x4D36FD1: QETWidget::translateMouseEvent(_XEvent const*) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== by 0x4D368AF: QApplication::x11ProcessEvent(_XEvent*) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== by 0x4D46760: QEventLoop::processEvents(unsigned) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== Address 0x2C is not stack'd, malloc'd or (recently) free'd

Per essere sicuro allega alla segnalazione del bug l'intero file log fornito da valgrind.

Development/Tutorials/Debugging/How to create useful crash reports (it)

2010-06-05T10:08:26Z

Panda84: Fix grassetto e un errore battitura.

{{Template:I18n/Language Navigation Bar|Development/Tutorials/Debugging/How to create useful crash reports}}

== Introduzione ==

Questo documento descrive come riprodurre un backtrace (ovvero una "traccia dell'esecuzione") di applicazioni KDE che vanno in crash. Inizialmente vengono fornite alcune informazioni generali; nel seguito vengono descritte le procedure per ottenere i pacchetti KDE per varie distribuzioni utili a ottenere i backtrace. Queste parti dovrebbero essere sufficienti per la maggior parte della gente. Ci sono alcune sezioni addizionali su come creare backtrace con il GNU Debugger e con Valgrind, che possono essere utili in alcuni casi.

== Come creare segnalazioni di crash utili ==

Una buona segnalazione di bug nel [http://bugs.kde.org Bugzilla] consiste di due parti: una '''descrizione''' di come riprodurre il crash ed un '''backtrace''' del crash stesso. Se manca uno di questi elementi risulta molto più difficile, se non impossibile, per gli sviluppatori affrontare il problema.

Una descrizione deve consistere di qualcosa più di un solo "si è piantato". È necessario cercare di descrivere qualsiasi cosa venga fatta prima del crash. È stato cliccato su un pulsante, aperto un particolare sito o file che ha causato il problema? Quel piccolo dettaglio che potrebbe sembrare inutile all'utente potrebbe risultare utile allo sviluppatore, quindi è sempre il caso di annotarlo nella segnalazione.

Un articolo approfondito su come scrivere delle buone descrizioni di bug e segnalazioni è disponibile a [http://www.chiark.greenend.org.uk/~sgtatham/bugs.html questo indirizzo], è caldamente consigliato leggerlo prima di effettuare delle segnalazioni.

Il backtrace di un crash non va allegato alla segnalazione; va semplicemente incollato in coda al testo della segnalazione stessa. In questo modo è molto più semplice per gli sviluppatori individuare segnalazioni duplicate dello stesso bug, in quanto la ricerca non avviene anche sul testo degli allegati.

Se si incolla un backtrace in una segnalazione assicurarsi di rimuovere tutte le righe, eccetto un paio, del tipo:

(no debugging symbols found)

dal backtrace, in quanto lo rendono più difficile da leggere.

Sebbene incollare backtrace direttamente sia preferibile rispetto ad aggiungere un allegato, non vanno incollate altre cose come log (valgrind, strace o output del terminale) o esempi di dati (email, file HTML e così via); per queste cose vanno usati gli allegati.

=== Backtrace ===

I backtrace sono essenziali. Possono sembrare senza significato per i non addetti, ma in realtà possono contenere una gran quantità di informazioni utili. Un backtrace descrive quali funzioni sono state chiamate prima del crash, in modo che gli sviluppatori possano tracciare in quale metodo è partito il problema. Ottenere buoni backtrace ha uno svantaggio: [[Development/Tutorials/Debugging/Debugging_symbols|le librerie e gli eseguibili occupano molto più spazio rispetto alla versione ottimizzata]]. È per questo motivo che molte distribuzioni scelgono di installare file senza simboli di debugging, '''cosa che causa la creazione di backtrace inutili''' come questo:

(no debugging symbols found)
Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread -1233848624 (LWP 12212)]
[New Thread -1255081072 (LWP 12820)]
[New Thread -1240921200 (LWP 12819)]
[New Thread -1266680944 (LWP 12818)]
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
0xffffe410 in __kernel_vsyscall ()
#0 0xffffe410 in __kernel_vsyscall ()
#1 0xb6a1210b in ?? () from /lib/tls/i686/cmov/libpthread.so.0
#2 0xb6a85afe in ?? () from /usr/lib/libX11.so.6
#3 0x00000003 in ?? ()
#4 0x082149c0 in ?? ()
#5 0x00003ffc in ?? ()
#6 0x00000000 in ?? ()

Per fortuna non c'è da preoccuparsi, con alcune modifiche è possibile creare backtrace con tutte le informazioni necessarie per le applicazioni KDE.

=== Preparare i pacchetti KDE ===

Se la distribuzione in uso ha pacchetti predisposti per il debugging è necessario installarli.

È facile vedere quali pacchetti di debug manchino guardando il backtrace. Prendiamo in considerazione la seguente linea di una backtrace:

#6 0xb7975bdc in ?? () from /usr/lib/libkmailprivate.so.4

Il simbolo <tt>??</tt> indica che la libreria <tt>libkmailprivate.so.4</tt> è priva di informazioni di debug, che potrebbero essere disponibili in pacchetti di debug separati. In questo caso, è facile capire che è necessario installare i pacchetti di debug per KMail per ottenere un backtrace migliore.

Alcune volte, c'è bisogno di installare più di un pacchetto di debug per ottenere un buon backtrace. Ciò dipende da come le distribuzioni suddividono i pacchetti. Per esempio, per alcune distribuzioni è sufficiente installare il pacchetto per <tt>kdepim</tt> per avere sufficienti informazioni riguardo un crash in KMail, in altre distribuzioni c'è un pacchetto di debug aggiuntivo per KMail.

Qui c'è una lista di come ottenere i pacchetti di debug per alcune distribuzioni:

*'''Debian''' - Debian offre pacchetti <tt>-dbg</tt> per creare facilmente backtrace utili. Basta installare il corrispondente pacchetto <tt>-dbg</tt>. ad esempio <tt>kdepim-dbg</tt> per i crash di KMail. Le dipendenze di -dbg assicurano di ottenere anche gli altri pacchetti necessari (kdelibs-dbg, gdb, e così via).
*'''FreeBSD ports''' - Fare riferimento alla pagina [http://freebsd.kde.org/faq.php#AKDEapplicationcrashedandIwanttofileabugreportathttpbugskdeorgbutthebacktraceintheKDECrashManagerisuselessWhatcanIdo delle FAQ di KDE su FreeBSD].
*'''Gentoo''' - Gentoo ha [http://www.gentoo.org/proj/en/qa/backtraces.xml una guida] che descrive come procedere.
*'''Mandriva''' - A partire da Mandriva 2007.0 in su ci sono pacchetti addizionali per tutto KDE. È sufficiente installare il corrispondente pacchetto <tt>-debug</tt>, come <tt>kdebase-debug</tt> e <tt>kdemultimedia-debug</tt>. Quasi certamente va installato <tt>kdelibs-debug</tt> in ogni caso.
** Nota: i pacchetti <tt>-debug</tt> sono in repository separati. Ad esempio, per tutti i pacchetti in <tt>main</tt>, si possono trovare i pacchetti di debug nel repository <tt>debug_main</tt>.
*'''Kubuntu/Ubuntu''' - La famiglia di distribuzioni Ubuntu rende le cose abbastanza facili. Ogni modulo ufficiale di KDE ha un pacchetto aggiuntivo nei repository con il suffisso <tt>-dbg</tt>. È importante installare sempre <tt>kdelibs5-dbg</tt>, in quanto tutte le applicazioni KDE usano kdelibs (kdelibs-dbg per applicazioni KDE 3). Oltre a ciò è necessario installare il pacchetto -dbg anche per l'applicazione che è andata in crash. Per esempio se si è piantato KOrganizer è necessario installare anche <tt>kdepim-dbg</tt>. Se il programma non fa parte di un modulo ufficiale di KDE e non ha un apposito pacchetto -dbg, è possibile installare il pacchetto -dbgsym dal repository in questa [https://wiki.kubuntu.org/DebuggingProgramCrash pagina sul debugging dei programmi].
** Durante il ciclo di sviluppo di Ubuntu il gestore di crash Apport è attivo e si preoccuperà di riportare i crash a launchpad.net e creare il backtrace per te. Se si desidera utilizzare il gestore dei crash di KDE è possibile disabilitarlo nel file /etc/defaults/apport
** A partire da Lucid Lynx (10.04) Kubuntu inoltrerà tutti i bug che non sono peculiari della distribuzione al sistema di gestione di KDE; Apport è ora disabilitato in modo da utilizzare DrKonqui come gestore predefinito dei crash.
*'''openSUSE''' - È necessario solo installare i pacchetti <tt>-debuginfo</tt>, ad esempio: <tt>kdepimlibs4-debuginfo</tt>. È possibile trovare questi pacchetti nei [http://en.opensuse.org/KDE/Repositories repository KDE]. C'è anche una [http://en.opensuse.org/Bugs:An_application_crashed pagina dedicata al debugging in openSUSE].
*'''Fedora''' - In Fedora è sufficiente utilizzare i seguenti comandi:
*# <tt>yum provides "/usr/lib/libkmailprivate.so.4"</tt> per trovare quale pacchetto fornisce quel file;
*# <tt>debuginfo-install kdepim</tt> da utente root per installare i pacchetti di debug per quel pacchetto (dipendenze incluse).
*: Una guida completa e dettagliata per Fedora è disponibile in [http://fedoraproject.org/wiki/StackTraces questo documento] che descrive come procedere. Fedora utilizza un repository debuginfo separato che va abilitato. Si consiglia anche di utilizzare il plugin yum <tt>auto-update-debug-info</tt> per tenere aggiornati i pacchetti debuginfo.

Nel raro caso in cui la distribuzione non abbia pacchetti di contenente i simboli di debug per KDE, è necessario compilare KDE dai sorgenti:

* Nel caso di KDE 3, al passo di configure, è necessario passare il parametro <tt>--enable-debug=full</tt> al fine di creare i simboli di debug nei file risultanti.
* Nel caso di KDE 4, al passo di cmake, è necessario passare il parametro <tt>-DCMAKE_BUILD_TYPE=debugfull</tt>. Se si vuole passare opzioni personalizzate a CXXFLAGS, utilizzare <tt>-DCMAKE_BUILD_TYPE=None CMAKE_CXX_FLAGS="-O0 -g"</tt>. È possibile cambiare le opzioni CMAKE_CXX_FLAGS in base alle proprie necessità.

Dopodiché è sufficiente dare <tt>make</tt> e <tt>make install</tt> come al solito.

===Crash!===

Ora che sono state reperite le informazioni per rendere utile la traccia dell'esecuzione va riprodotto il crash nell'applicazione. La finestra di dialogo di KDE apparirà qualche istante dopo al crash dell'applicazione.

[[Image:Kde-crash-handler.png|center|300px|La finestra di dialogo dei crash di KDE]]

Ora la generazione del backtrace dovrebbe risultare molto più completa, ad esempio:

Using host libthread_db library "/lib/libthread_db.so.1".
[Thread debugging using libthread_db enabled]
[New Thread -1232783168 (LWP 7604)]
[KCrash handler]
#6 0x0806be76 in TreeMapItem::parent (this=0x0)
at /home/bram/KDE/kde3/kdeaddons/konq-plugins/fsview/treemap.h:285
#7 0x08065fea in TreeMapItemList::compareItems (this=0xbfec04a8, item1=0x0,
item2=0x0)
at /home/bram/KDE/kde3/kdeaddons/konq-plugins/fsview/treemap.cpp:720
#8 0xb7281619 in QGList::operator== () from /usr/qt/3/lib/libqt-mt.so.3
#9 0x0806d498 in QPtrList<TreeMapItem>::operator== (this=0xbfec04a8,
list=@0xbfec0468) at /usr/qt/3/include/qptrlist.h:74
#10 0x08062e18 in TreeMapWidget::mousePressEvent (this=0xbfec03ac,
e=0xbfebff1c)
at /home/bram/KDE/kde3/kdeaddons/konq-plugins/fsview/treemap.cpp:1840
#11 0xb7004a63 in QWidget::event () from /usr/qt/3/lib/libqt-mt.so.3
#12 0xb6f6bca7 in QApplication::internalNotify ()
from /usr/qt/3/lib/libqt-mt.so.3
#13 0xb6f6ca88 in QApplication::notify () from /usr/qt/3/lib/libqt-mt.so.3
#14 0xb7725a84 in KApplication::notify (this=0xbfec055c, receiver=0xbfec03ac,
event=0xbfebff1c)
at /home/bram/KDE/kde3/kdelibs/kdecore/kapplication.cpp:550
#15 0xb6f0bfd2 in QETWidget::translateMouseEvent ()
from /usr/qt/3/lib/libqt-mt.so.3
#16 0xb6f0b8b0 in QApplication::x11ProcessEvent ()
from /usr/qt/3/lib/libqt-mt.so.3
#17 0xb6f1b761 in QEventLoop::processEvents () from /usr/qt/3/lib/libqt-mt.so.3
#18 0xb6f82831 in QEventLoop::enterLoop () from /usr/qt/3/lib/libqt-mt.so.3
#19 0xb6f826b6 in QEventLoop::exec () from /usr/qt/3/lib/libqt-mt.so.3
#20 0xb6f6b72f in QApplication::exec () from /usr/qt/3/lib/libqt-mt.so.3
#21 0x0805181e in main (argc=134673960, argv=0xffffffff)
at /home/bram/KDE/kde3/kdeaddons/konq-plugins/fsview/main.cpp:55

Molto meglio, vero? In questo backtrace sono presenti gli indirizzi di memoria, i file sorgenti, i numeri di riga e i parametri passati alle funzioni che hanno causato il problema. Ciò rende più facile per gli sviluppatori capire la causa del problema, in quanto sa dove guardare.

{{note|È '''obbligatorio''' avere GDB installato per ottenere il backtrace di un crash. Nella sezione seguente è spiegato cos'è GDB e come installarlo.}}

===Ottenere un backtrace con GDB===

In alcuni casi non è possibile creare un backtrace con la finestra di dialogo dei crash di KDE. Ciò può essere dovuto da un'applicazione entrata in un loop infinito, o dal fatto che la finestra del crash non è apparsa per qualche motivo. In tali casi è possibile ottenere un backtrace con <tt>gdb</tt>, il [http://sourceware.org/gdb/ Debugger GNU]. GDB è disponibile pacchettizzato per tutte le distribuzioni più importanti.

Il richiamo di GDB dipende dalle situazioni. È possibile sia eseguire un'applicazione all'interno di gdb che collegare gdb ad un processo già in esecuzione. Quest'ultima situazione in particolare è utile quando un'applicazione è già entrata in un loop infinito. Cominciamo con la prima soluzione; per eseguire un'applicazione da gdb digitare sulla riga di comando:

$ gdb someKDEapp

Apparirà il prompt di GDB. Per avviare l'applicazione, al momento non ancora avviata, è necessario invocare il comando<tt>run</tt>:

(gdb) run

{{note|Alcune applicazioni di KDE (ad esempio JuK e KTorrent) contengono del codice speciale per assicurarsi che ci sia una sola istanza dell'applicazione avviata alla volta. Per queste applicazioni è bisogna utilizzare il comando "run --nofork" al prompt di (gdb) invece di "run" perché altrimenti gdb proverebbe a debuggare il processo sbagliato. In caso di dubbio su quale usare è sufficiente provare ad avviare l'applicazione con l'opzione --nofork: se l'applicazione dice che è un'opzione sconosciuta è possibile rimuovere l'opzione --nofork.}}

Questo avvierà l'applicazione a cui siete abituati, e vi permetterà di lavorarci come fate solitamente (con la differenza che consumerà molta più memoria e potrebbe risultare molto più lenta). Ora va riprodotto il crash. Quando l'applicazione va in crash essa si chiuderà riportando al prompt di GDB. Ora è necessario invocare il comando 'backtrace':

(gdb) thread apply all backtrace

Ciò dovrebbe fornire una buona backtrace che può essere inserita nel Bugzilla di KDE.

In caso si voglia collegarsi ad un processo già esistente va invocato il seguente comando:

$ gdb someKDEapp pid

dove ''pid'' è il process ID del processo al quale ci si vuole collegare. Una volta collegati, quando il processo è in un ciclo infinito, dopo aver usato il comando 'backtrace' apparirà una traccia dell'esecuzione. È possibile utilizzare il comando 'continue' per lasciare l'applicazione eseguire nuovamente e premere Ctrl+C in gdb per poter inserire nuovamente dei comandi.

===Ottenere un backtrace con Valgrind===

Un altro strumento utile per creare backtrace di crash è [http://www.valgrind.org Valgrind]; esso non sostituisce GDB, ma piuttosto lo completa.

Quando si esegue un'applicazione in valgrind ogni pezzo di memoria letta o scritta dall'applicazione stessa viene controllato. Valgrind riporterà operazioni non valide in memoria nello standard output o in un file di log. Dato che la maggior parte dei crash sono dovuti a letture invalide in memoria, Valgrind può essere utile per tracciare dove succedono i problemi.

{{note|Valgrind consiste di vari tool per verificare o effettuare la profilazione di un'applicazione. In questo articolo useremo solo memcheck, il tool di default che viene chiamato all'esecuzione di valgrind.}}

Come GDB, Valgrind rende l'esecuzione delle applicazioni molto più lento e più esoso in termini di risorse.

Per avviare l'applicazione all'interno di valgrind:

$ valgrind --log-file=someKDEapp someKDEapp

Ora va riprodotto il crash. Appena avviene sia l'applicazione che valgrind termineranno. Ciò che rimane è un file con nome <tt>someKDEapp.pid</tt> dove ''pid'' sarà il process ID del processo valgrind. Il file potrebbe elencare più errori di quanti siano effettivamente causa del crash. Qui c'è un esempio della parte che causa il crash che corrisponde al backtrace GDB sopra:

==23292== Invalid read of size 4
==23292== at 0x806BD9E: TreeMapItem::parent() const (treemap.h:285)
==23292== by 0x8065FB9: TreeMapItemList::compareItems(void*, void*) (treemap.cpp:720)
==23292== by 0x50AC618: QGList::operator==(QGList const&) const (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== by 0x806D3BF: QPtrList<TreeMapItem>::operator==(QPtrList<TreeMapItem> const&) const (qptrlist.h:74)
==23292== by 0x8062DE7: TreeMapWidget::mousePressEvent(QMouseEvent*) (treemap.cpp:1840)
==23292== by 0x4E2FA62: QWidget::event(QEvent*) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== by 0x4D96CA6: QApplication::internalNotify(QObject*, QEvent*) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== by 0x4D97A87: QApplication::notify(QObject*, QEvent*) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== by 0x4809AC3: KApplication::notify(QObject*, QEvent*) (kapplication.cpp:550)
==23292== by 0x4D36FD1: QETWidget::translateMouseEvent(_XEvent const*) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== by 0x4D368AF: QApplication::x11ProcessEvent(_XEvent*) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== by 0x4D46760: QEventLoop::processEvents(unsigned) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== Address 0x2C is not stack'd, malloc'd or (recently) free'd

Per essere sicuro allega alla segnalazione del bug l'intero file log fornito da valgrind.

Development/Tutorials/Debugging/How to create useful crash reports (it)

2010-06-02T15:33:27Z

Panda84: Corretto errore ortografia.

{{Template:I18n/Language Navigation Bar|Development/Tutorials/Debugging/How to create useful crash reports}}

== Introduzione ==

Questo documento descrive come riprodurre un backtrace (ovvero una "traccia dell'esecuzione") di applicazioni KDE che vanno in crash. Inizialmente vengono fornite alcune informazioni generali; nel seguito vengono descritte le procedure per ottenere i pacchetti KDE per varie distribuzioni utili a ottenere i backtrace. Queste parti dovrebbero essere sufficienti per la maggior parte della gente. Ci sono alcune sezioni addizionali su come creare backtrace con il GNU Debugger e con Valgrind, che possono essere utili in alcuni casi.

== Come creare segnalazioni di crash utili ==

Una buona segnalazione di bug nel [http://bugs.kde.org Bugzilla] consiste di due parti: una '''descrizione''' di come riprodurre il crash ed un '''backtrace''' del crash stesso. Se manca uno di questi elementi risulta molto più difficile, se non impossibile, per gli sviluppatori affrontare il problema.

Una descrizione deve consistere di qualcosa più di un solo "si è piantato". È necessario cercare di descrivere qualsiasi cosa venga fatta prima del crash. È stato cliccato su un pulsante, aperto un particolare sito o file che ha causato il problema? Quel piccolo dettaglio che potrebbe sembrare inutile all'utente potrebbe risultare utile allo sviluppatore, quindi è sempre il caso di annotarlo nella segnalazione.

Un articolo approfondito su come scrivere delle buone descrizioni di bug e segnalazioni è disponibile a [http://www.chiark.greenend.org.uk/~sgtatham/bugs.html questo indirizzo], è caldamente consigliato leggerlo prima di effettuare delle segnalazioni.

Il backtrace di un crash non va allegato alla segnalazione; va semplicemente incollato in coda al testo della segnalazione stessa. In questo modo è molto più semplice per gli sviluppatori individuare segnalazioni duplicate dello stesso bug, in quanto la ricerca non avviene anche sul testo degli allegati.

Se si incolla un backtrace in una segnalazione assicurarsi di rimuovere tutte le righe, eccetto un paio, del tipo:

(no debugging symbols found)

dal backtrace, in quanto lo rendono più difficile da leggere.

Sebbene incollare backtrace direttamente sia preferibile rispetto ad aggiungere un allegato, non vanno incollate altre cose come log (valgrind, strace o output del terminale) o esempi di dati (email, file HTML e così via); per queste cose vanno usati gli allegati.

=== Backtrace ===

I backtrace sono essenziali. Possono sembrare senza significato per i non addetti, ma in realtà possono contenere una gran quantità di informazioni utili. Un backtrace descrive quali funzioni sono state chiamate prima del crash, in modo che gli sviluppatori possano tracciare in quale metodo è partito il problema. Ottenere buoni backtrace ha uno svantaggio: [[Development/Tutorials/Debugging/Debugging_symbols|le librerie e gli eseguibili occupano molto più spazio rispetto alla versione ottimizzata]]. È per questo motivo che molte distribuzioni scelgono di installare file senza simboli di debugging, '''che causa la creazione di backtrace inutili":

(no debugging symbols found)
Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread -1233848624 (LWP 12212)]
[New Thread -1255081072 (LWP 12820)]
[New Thread -1240921200 (LWP 12819)]
[New Thread -1266680944 (LWP 12818)]
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
0xffffe410 in __kernel_vsyscall ()
#0 0xffffe410 in __kernel_vsyscall ()
#1 0xb6a1210b in ?? () from /lib/tls/i686/cmov/libpthread.so.0
#2 0xb6a85afe in ?? () from /usr/lib/libX11.so.6
#3 0x00000003 in ?? ()
#4 0x082149c0 in ?? ()
#5 0x00003ffc in ?? ()
#6 0x00000000 in ?? ()

Per fortuna non c'è da preoccuparsi, con alcune modifiche è possibile creare backtrace con tutte le informazioni necessarie per le applicazioni KDE.

=== Preparare i pacchetti KDE ===

Se la tua distribuzione ha pacchetti predisposti per il debugging è necessario installarli.

È facile vedere quali pacchetti di debug manchino guardando al backtrace. Prendiamo in considerazione la seguente linea di una backtrace:

#6 0xb7975bdc in ?? () from /usr/lib/libkmailprivate.so.4

Il simbolo <tt>??</tt> indica che la libreria <tt>libkmailprivate.so.4</tt> è priva di informazioni di debug, che potrebbero essere disponibili in pacchetti di debug separati. In questo caso, è facile capire che è necessario installare i pacchetti di debug per KMail per ottenere un backtrace migliore.

Alcune volte, c'è bisogno di installare più di un pacchetto di debug per ottenere un buon backtrace. Ciò dipende da come le distribuzioni suddividono i pacchetti. Per esempio, per alcune distribuzioni è sufficiente installare il pacchetto per <tt>kdepim</tt> per avere sufficienti informazioni riguardo un crash in KMail, in altre distribuzioni c'è un pacchetto di debug aggiuntivo per KMail.

Qui c'è una lista di come ottenere i pacchetti di debug per alcune distribuzioni:

*'''Debian''' - Debian offre pacchetti <tt>-dbg</tt> per creare facilmente backtrace utili. Basta installare il corrispondente pacchetto <tt>-dbg</tt>. ad esempio <tt>kdepim-dbg</tt> per i crash di KMail. Le dipendenze di -dbg assicurano di ottenere anche gli altri pacchetti necessari (kdelibs-dbg, gdb, e così via).
*'''FreeBSD ports''' - Fare riferimento alla pagina [http://freebsd.kde.org/faq.php#AKDEapplicationcrashedandIwanttofileabugreportathttpbugskdeorgbutthebacktraceintheKDECrashManagerisuselessWhatcanIdo delle FAQ di KDE su FreeBSD].
*'''Gentoo''' - Gentoo ha [http://www.gentoo.org/proj/en/qa/backtraces.xml una guida] che descrive come procedere.
*'''Mandriva''' - A partire da Mandriva 2007.0 in su ci sono pacchetti addizionali per tutto KDE. È sufficiente installare il corrispondente pacchetto <tt>-debug</tt>, come <tt>kdebase-debug</tt> e <tt>kdemultimedia-debug</tt>. Quasi certamente va installato <tt>kdelibs-debug</tt> in ogni caso.
** Nota: i pacchetti <tt>-debug</tt> sono in repository separati. Ad esempio, per tutti i pacchetti in <tt>main</tt>, si possono trovare i pacchetti di debug nel repository <tt>debug_main</tt>.
*'''Kubuntu/Ubuntu''' - La famiglia di distribuzioni Ubuntu rende le cose abbastanza facili. Ogni modulo ufficiale di KDE ha un pacchetto aggiuntivo nei repository con il suffisso <tt>-dbg</tt>. È importante installare sempre <tt>kdelibs5-dbg</tt>, in quanto tutte le applicazioni KDE usano kdelibs (kdelibs-dbg per applicazioni KDE 3). Oltre a ciò è necessario installare il pacchetto -dbg anche per l'applicazione che è andata in crash. Per esempio se si è piantato KOrganizer è necessario installare anche <tt>kdepim-dbg</tt>. Se il programma non fa parte di un modulo ufficiale di KDE e non ha un apposito pacchetto -dbg, è possibile installare il pacchetto -dbgsym dal repository in questa [https://wiki.kubuntu.org/DebuggingProgramCrash pagina sul debugging dei programmi].
** Durante il ciclo di sviluppo di Ubuntu il gestore di crash Apport è attivo e si preoccuperà di riportare i crash a launchpad.net e creare il backtrace per te. Se si desidera utilizzare il gestore dei crash di KDE è possibile disabilitarlo nel file /etc/defaults/apport
** A partire da Lucid Lynx (10.04) Kubuntu inoltrerà tutti i bug che non sono peculiari della distribuzione al sistema di gestione di KDE; Apport è ora disabilitato in modo da utilizzare DrKonqui come gestore predefinito dei crash.
*'''openSUSE''' - È necessario solo installare i pacchetti <tt>-debuginfo</tt>, ad esempio: <tt>kdepimlibs4-debuginfo</tt>. È possibile trovare questi pacchetti nei [http://en.opensuse.org/KDE/Repositories repository KDE]. C'è anche una [http://en.opensuse.org/Bugs:An_application_crashed pagina dedicata al debugging in openSUSE].
*'''Fedora''' - In Fedora è sufficiente utilizzare i seguenti comandi:
*# <tt>yum provides "/usr/lib/libkmailprivate.so.4"</tt> per trovare quale pacchetto fornisce quel file;
*# <tt>debuginfo-install kdepim</tt> da utente root per installare i pacchetti di debug per quel pacchetto (dipendenze incluse).
*: Una guida completa e dettagliata per Fedora è disponibile in [http://fedoraproject.org/wiki/StackTraces questo documento] che descrive come procedere. Fedora utilizza un repository debuginfo separato che va abilitato. Si consiglia anche di utilizzare il plugin yum <tt>auto-update-debug-info</tt> per tenere aggiornati i pacchetti debuginfo.

Nel raro caso in cui la distribuzione non abbia pacchetti di contenente i simboli di debug per KDE, è necessario compilare KDE dai sorgenti:

* Nel caso di KDE 3, al passo di configure, è necessario passare il parametro <tt>--enable-debug=full</tt> al fine di creare i simboli di debug nei file risultanti.
* Nel caso di KDE 4, al passo di cmake, è necessario passare il parametro <tt>-DCMAKE_BUILD_TYPE=debugfull</tt>. Se si vuole passare opzioni personalizzate a CXXFLAGS, utilizzare <tt>-DCMAKE_BUILD_TYPE=None CMAKE_CXX_FLAGS="-O0 -g"</tt>. È possibile cambiare le opzioni CMAKE_CXX_FLAGS in base alle proprie necessità.

Dopodiché è sufficiente dare <tt>make</tt> e <tt>make install</tt> come al solito.

===Crash!===

Ora che sono state reperite le informazioni per rendere utile la traccia dell'esecuzione va riprodotto il crash nell'applicazione. La finestra di dialogo di KDE apparirà qualche istante dopo al crash dell'applicazione.

[[Image:Kde-crash-handler.png|center|300px|La finestra di dialogo dei crash di KDE]]

Ora la generazione del backtrace dovrebbe risultare molto più completa, ad esempio:

Using host libthread_db library "/lib/libthread_db.so.1".
[Thread debugging using libthread_db enabled]
[New Thread -1232783168 (LWP 7604)]
[KCrash handler]
#6 0x0806be76 in TreeMapItem::parent (this=0x0)
at /home/bram/KDE/kde3/kdeaddons/konq-plugins/fsview/treemap.h:285
#7 0x08065fea in TreeMapItemList::compareItems (this=0xbfec04a8, item1=0x0,
item2=0x0)
at /home/bram/KDE/kde3/kdeaddons/konq-plugins/fsview/treemap.cpp:720
#8 0xb7281619 in QGList::operator== () from /usr/qt/3/lib/libqt-mt.so.3
#9 0x0806d498 in QPtrList<TreeMapItem>::operator== (this=0xbfec04a8,
list=@0xbfec0468) at /usr/qt/3/include/qptrlist.h:74
#10 0x08062e18 in TreeMapWidget::mousePressEvent (this=0xbfec03ac,
e=0xbfebff1c)
at /home/bram/KDE/kde3/kdeaddons/konq-plugins/fsview/treemap.cpp:1840
#11 0xb7004a63 in QWidget::event () from /usr/qt/3/lib/libqt-mt.so.3
#12 0xb6f6bca7 in QApplication::internalNotify ()
from /usr/qt/3/lib/libqt-mt.so.3
#13 0xb6f6ca88 in QApplication::notify () from /usr/qt/3/lib/libqt-mt.so.3
#14 0xb7725a84 in KApplication::notify (this=0xbfec055c, receiver=0xbfec03ac,
event=0xbfebff1c)
at /home/bram/KDE/kde3/kdelibs/kdecore/kapplication.cpp:550
#15 0xb6f0bfd2 in QETWidget::translateMouseEvent ()
from /usr/qt/3/lib/libqt-mt.so.3
#16 0xb6f0b8b0 in QApplication::x11ProcessEvent ()
from /usr/qt/3/lib/libqt-mt.so.3
#17 0xb6f1b761 in QEventLoop::processEvents () from /usr/qt/3/lib/libqt-mt.so.3
#18 0xb6f82831 in QEventLoop::enterLoop () from /usr/qt/3/lib/libqt-mt.so.3
#19 0xb6f826b6 in QEventLoop::exec () from /usr/qt/3/lib/libqt-mt.so.3
#20 0xb6f6b72f in QApplication::exec () from /usr/qt/3/lib/libqt-mt.so.3
#21 0x0805181e in main (argc=134673960, argv=0xffffffff)
at /home/bram/KDE/kde3/kdeaddons/konq-plugins/fsview/main.cpp:55

Molto meglio, vero? In questo backtrace sono presenti gli indirizzi di memoria, i file sorgenti, i numeri di riga e i parametri passati alle funzioni che hanno causato il problema. Ciò rende più facile per gli sviluppatori capire la causa del problema, in quanto sa dove guardare.

{{note|È '''obbligatorio''' avere GDB installato per ottenere il backtrace di un crash. Nella sezione seguente è spiegato cos'è GDB e come installarlo.}}

===Ottenere un backtrace con GDB===

In alcuni casi non è possibile creare un backtrace con la finestra di dialogo dei crash di KDE. Ciò può essere dovuto da un'applicazione entrata in un loop infinito, o dal fatto che la finestra del crash non è apparsa per qualche motivo. In tali casi è possibile ottenere un backtrace con <tt>gdb</tt>, il [http://sourceware.org/gdb/ Debugger GNU]. GDB è disponibile pacchettizzato per tutte le distribuzioni più importanti.

Il richiamo di GDB dipende dalle situazioni. È possibile sia eseguire un'applicazione all'interno di gdb che collegare gdb ad un processo già in esecuzione. Quest'ultima situazione in particolare è utile quando un'applicazione è già entrata in un loop infinito. Cominciamo con la prima soluzione; per eseguire un'applicazione da gdb digitare sulla riga di comando:

$ gdb someKDEapp

Apparirà il prompt di GDB. Per avviare l'applicazione, al momento non ancora avviata, è necessario invocare il comando<tt>run</tt>:

(gdb) run

{{note|Alcune applicazioni di KDE (ad esempio JuK e KTorrent) contengono del codice speciale per assicurarsi che ci sia una sola istanza dell'applicazione avviata alla volta. Per queste applicazioni è bisogna utilizzare il comando "run --nofork" al prompt di (gdb) invece di "run" perché altrimenti gdb proverebbe a debuggare il processo sbagliato. In caso di dubbio su quale usare è sufficiente provare ad avviare l'applicazione con l'opzione --nofork: se l'applicazione dice che è un'opzione sconosciuta è possibile rimuovere l'opzione --nofork.}}

Questo avvierà l'applicazione a cui siete abituati, e vi permetterà di lavorarci come fate solitamente (con la differenza che consumerà molta più memoria e potrebbe risultare molto più lenta). Ora va riprodotto il crash. Quando l'applicazione va in crash essa si chiuderà riportando al prompt di GDB. Ora è necessario invocare il comando 'backtrace':

(gdb) thread apply all backtrace

Ciò dovrebbe fornire una buona backtrace che può essere inserita nel Bugzilla di KDE.

In caso si voglia collegarsi ad un processo già esistente va invocato il seguente comando:

$ gdb someKDEapp pid

dove ''pid'' è il process ID del processo al quale ci si vuole collegare. Una volta collegati, quando il processo è in un ciclo infinito, dopo aver usato il comando 'backtrace' apparirà una traccia dell'esecuzione. È possibile utilizzare il comando 'continue' per lasciare l'applicazione eseguire nuovamente e premere Ctrl+C in gdb per poter inserire nuovamente dei comandi.

===Ottenere un backtrace con Valgrind===

Un altro strumento utile per creare backtrace di crash è [http://www.valgrind.org Valgrind]; esso non sostituisce GDB, ma piuttosto lo completa.

Quando si esegue un'applicazione in valgrind ogni pezzo di memoria letta o scritta dall'applicazione stessa viene controllato. Valgrind riporterà operazioni non valide in memoria nello standard output o in un file di log. Dato che la maggior parte dei crash sono dovuti a letture invalide in memoria, Valgrind può essere utile per tracciare dove succedono i problemi.

{{note|Valgrind consiste di vari tool per verificare o effettuare la profilazione di un'applicazione. In questo articolo useremo solo memcheck, il tool di default che viene chiamato all'esecuzione di valgrind.}}

Come GDB, Valgrind rende l'esecuzione delle applicazioni molto più lento e più esoso in termini di risorse.

Per avviare l'applicazione all'interno di valgrind:

$ valgrind --log-file=someKDEapp someKDEapp

Ora va riprodotto il crash. Appena avviene sia l'applicazione che valgrind termineranno. Ciò che rimane è un file con nome <tt>someKDEapp.pid</tt> dove ''pid'' sarà il process ID del processo valgrind. Il file potrebbe elencare più errori di quanti siano effettivamente causa del crash. Qui c'è un esempio della parte che causa il crash che corrisponde al backtrace GDB sopra:

==23292== Invalid read of size 4
==23292== at 0x806BD9E: TreeMapItem::parent() const (treemap.h:285)
==23292== by 0x8065FB9: TreeMapItemList::compareItems(void*, void*) (treemap.cpp:720)
==23292== by 0x50AC618: QGList::operator==(QGList const&) const (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== by 0x806D3BF: QPtrList<TreeMapItem>::operator==(QPtrList<TreeMapItem> const&) const (qptrlist.h:74)
==23292== by 0x8062DE7: TreeMapWidget::mousePressEvent(QMouseEvent*) (treemap.cpp:1840)
==23292== by 0x4E2FA62: QWidget::event(QEvent*) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== by 0x4D96CA6: QApplication::internalNotify(QObject*, QEvent*) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== by 0x4D97A87: QApplication::notify(QObject*, QEvent*) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== by 0x4809AC3: KApplication::notify(QObject*, QEvent*) (kapplication.cpp:550)
==23292== by 0x4D36FD1: QETWidget::translateMouseEvent(_XEvent const*) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== by 0x4D368AF: QApplication::x11ProcessEvent(_XEvent*) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== by 0x4D46760: QEventLoop::processEvents(unsigned) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== Address 0x2C is not stack'd, malloc'd or (recently) free'd

Per essere sicuro allega alla segnalazione del bug l'intero file log fornito da valgrind.

Development/Tutorials/Debugging/How to create useful crash reports (it)

2010-06-02T15:25:02Z

Panda84: Sezione "valgrind" tradotta.

{{Template:I18n/Language Navigation Bar|Development/Tutorials/Debugging/How to create useful crash reports}}

== Introduzione ==

Questo documento descrive come riprodurre un backtrace (ovvero una "traccia dell'esecuzione") di applicazioni KDE che vanno in crash. Inizialmente vengono fornite alcune informazioni generali; nel seguito vengono descritte le procedure per ottenere i pacchetti KDE per varie distribuzioni utili a ottenere i backtrace. Queste parti dovrebbero essere sufficienti per la maggior parte della gente. Ci sono alcune sezioni addizionali su come creare backtrace con il GNU Debugger e con Valgrind, che possono essere utili in alcuni casi.

== Come creare segnalazioni di crash utili ==

Una buona segnalazione di bug nel [http://bugs.kde.org Bugzilla] consiste di due parti: una '''descrizione''' di come riprodurre il crash ed un '''backtrace''' del crash stesso. Se manca uno di questi elementi risulta molto più difficile, se non impossibile, per gli sviluppatori affrontare il problema.

Una descrizione deve consistere di qualcosa più di un solo "si è piantato". È necessario cercare di descrivere qualsiasi cosa venga fatta prima del crash. È stato cliccato su un pulsante, aperto un particolare sito o file che ha causato il problema? Quel piccolo dettaglio che potrebbe sembrare inutile all'utente potrebbe risultare utile allo sviluppatore, quindi è sempre il caso di annotarlo nella segnalazione.

Un articolo approfondito su come scrivere delle buone descrizioni di bug e segnalazioni è disponibile a [http://www.chiark.greenend.org.uk/~sgtatham/bugs.html questo indirizzo], è caldamente consigliato leggerlo prima di effettuare delle segnalazioni.

Il backtrace di un crash non va allegato alla segnalazione; va semplicemente incollato in coda al testo della segnalazione stessa. In questo modo è molto più semplice per gli sviluppatori individuare segnalazioni duplicate dello stesso bug, in quanto la ricerca non avviene anche sul testo degli allegati.

Se si incolla un backtrace in una segnalazione assicurarsi di rimuovere tutte le righe, eccetto un paio, del tipo:

(no debugging symbols found)

dal backtrace, in quanto lo rendono più difficile da leggere.

Sebbene incollare backtrace direttamente sia preferibile rispetto ad aggiungere un allegato, non vanno incollate altre cose come log (valgrind, strace o output del terminale) o esempi di dati (email, file HTML e così via); per queste cose vanno usati gli allegati.

=== Backtrace ===

I backtrace sono essenziali. Possono sembrare senza significato per i non addetti, ma in realtà possono contenere una gran quantità di informazioni utili. Un backtrace descrive quali funzioni sono state chiamate prima del crash, in modo che gli sviluppatori possano tracciare in quale metodo è partito il problema. Ottenere buoni backtrace ha uno svantaggio: [[Development/Tutorials/Debugging/Debugging_symbols|le librerie e gli eseguibili occupano molto più spazio rispetto alla versione ottimizzata]]. È per questo motivo che molte distribuzioni scelgono di intallare file senza simboli di debugging, '''che causa la creazione di backtrace inutili":

(no debugging symbols found)
Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread -1233848624 (LWP 12212)]
[New Thread -1255081072 (LWP 12820)]
[New Thread -1240921200 (LWP 12819)]
[New Thread -1266680944 (LWP 12818)]
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
0xffffe410 in __kernel_vsyscall ()
#0 0xffffe410 in __kernel_vsyscall ()
#1 0xb6a1210b in ?? () from /lib/tls/i686/cmov/libpthread.so.0
#2 0xb6a85afe in ?? () from /usr/lib/libX11.so.6
#3 0x00000003 in ?? ()
#4 0x082149c0 in ?? ()
#5 0x00003ffc in ?? ()
#6 0x00000000 in ?? ()

Per fortuna non c'è da preoccuparsi, con alcune modifiche è possibile creare backtrace con tutte le informazioni necessarie per le applicazioni KDE.

=== Preparare i pacchetti KDE ===

Se la tua distribuzione ha pacchetti predisposti per il debugging è necessario installarli.

È facile vedere quali pacchetti di debug manchino guardando al backtrace. Prendiamo in considerazione la seguente linea di una backtrace:

#6 0xb7975bdc in ?? () from /usr/lib/libkmailprivate.so.4

Il simbolo <tt>??</tt> indica che la libreria <tt>libkmailprivate.so.4</tt> è priva di informazioni di debug, che potrebbero essere disponibili in pacchetti di debug separati. In questo caso, è facile capire che è necessario installare i pacchetti di debug per KMail per ottenere un backtrace migliore.

Alcune volte, c'è bisogno di installare più di un pacchetto di debug per ottenere un buon backtrace. Ciò dipende da come le distribuzioni suddividono i pacchetti. Per esempio, per alcune distribuzioni è sufficiente installare il pacchetto per <tt>kdepim</tt> per avere sufficienti informazioni riguardo un crash in KMail, in altre distribuzioni c'è un pacchetto di debug aggiuntivo per KMail.

Qui c'è una lista di come ottenere i pacchetti di debug per alcune distribuzioni:

*'''Debian''' - Debian offre pacchetti <tt>-dbg</tt> per creare facilmente backtrace utili. Basta installare il corrispondente pacchetto <tt>-dbg</tt>. ad esempio <tt>kdepim-dbg</tt> per i crash di KMail. Le dipendenze di -dbg assicurano di ottenere anche gli altri pacchetti necessari (kdelibs-dbg, gdb, e così via).
*'''FreeBSD ports''' - Fare riferimento alla pagina [http://freebsd.kde.org/faq.php#AKDEapplicationcrashedandIwanttofileabugreportathttpbugskdeorgbutthebacktraceintheKDECrashManagerisuselessWhatcanIdo delle FAQ di KDE su FreeBSD].
*'''Gentoo''' - Gentoo ha [http://www.gentoo.org/proj/en/qa/backtraces.xml una guida] che descrive come procedere.
*'''Mandriva''' - A partire da Mandriva 2007.0 in su ci sono pacchetti addizionali per tutto KDE. È sufficiente installare il corrispondente pacchetto <tt>-debug</tt>, come <tt>kdebase-debug</tt> e <tt>kdemultimedia-debug</tt>. Quasi certamente va installato <tt>kdelibs-debug</tt> in ogni caso.
** Nota: i pacchetti <tt>-debug</tt> sono in repository separati. Ad esempio, per tutti i pacchetti in <tt>main</tt>, si possono trovare i pacchetti di debug nel repository <tt>debug_main</tt>.
*'''Kubuntu/Ubuntu''' - La famiglia di distribuzioni Ubuntu rende le cose abbastanza facili. Ogni modulo ufficiale di KDE ha un pacchetto aggiuntivo nei repository con il suffisso <tt>-dbg</tt>. È importante installare sempre <tt>kdelibs5-dbg</tt>, in quanto tutte le applicazioni KDE usano kdelibs (kdelibs-dbg per applicazioni KDE 3). Oltre a ciò è necessario installare il pacchetto -dbg anche per l'applicazione che è andata in crash. Per esempio se si è piantato KOrganizer è necessario installare anche <tt>kdepim-dbg</tt>. Se il programma non fa parte di un modulo ufficiale di KDE e non ha un apposito pacchetto -dbg, è possibile installare il pacchetto -dbgsym dal repository in questa [https://wiki.kubuntu.org/DebuggingProgramCrash pagina sul debugging dei programmi].
** Durante il ciclo di sviluppo di Ubuntu il gestore di crash Apport è attivo e si preoccuperà di riportare i crash a launchpad.net e creare il backtrace per te. Se si desidera utilizzare il gestore dei crash di KDE è possibile disabilitarlo nel file /etc/defaults/apport
** A partire da Lucid Lynx (10.04) Kubuntu inoltrerà tutti i bug che non sono peculiari della distribuzione al sistema di gestione di KDE; Apport è ora disabilitato in modo da utilizzare DrKonqui come gestore predefinito dei crash.
*'''openSUSE''' - È necessario solo installare i pacchetti <tt>-debuginfo</tt>, ad esempio: <tt>kdepimlibs4-debuginfo</tt>. È possibile trovare questi pacchetti nei [http://en.opensuse.org/KDE/Repositories repository KDE]. C'è anche una [http://en.opensuse.org/Bugs:An_application_crashed pagina dedicata al debugging in openSUSE].
*'''Fedora''' - In Fedora è sufficiente utilizzare i seguenti comandi:
*# <tt>yum provides "/usr/lib/libkmailprivate.so.4"</tt> per trovare quale pacchetto fornisce quel file;
*# <tt>debuginfo-install kdepim</tt> da utente root per installare i pacchetti di debug per quel pacchetto (dipendenze incluse).
*: Una guida completa e dettagliata per Fedora è disponibile in [http://fedoraproject.org/wiki/StackTraces questo documento] che descrive come procedere. Fedora utilizza un repository debuginfo separato che va abilitato. Si consiglia anche di utilizzare il plugin yum <tt>auto-update-debug-info</tt> per tenere aggiornati i pacchetti debuginfo.

Nel raro caso in cui la distribuzione non abbia pacchetti di contenente i simboli di debug per KDE, è necessario compilare KDE dai sorgenti:

* Nel caso di KDE 3, al passo di configure, è necessario passare il parametro <tt>--enable-debug=full</tt> al fine di creare i simboli di debug nei file risultanti.
* Nel caso di KDE 4, al passo di cmake, è necessario passare il parametro <tt>-DCMAKE_BUILD_TYPE=debugfull</tt>. Se si vuole passare opzioni personalizzate a CXXFLAGS, utilizzare <tt>-DCMAKE_BUILD_TYPE=None CMAKE_CXX_FLAGS="-O0 -g"</tt>. È possibile cambiare le opzioni CMAKE_CXX_FLAGS in base alle proprie necessità.

Dopodiché è sufficiente dare <tt>make</tt> e <tt>make install</tt> come al solito.

===Crash!===

Ora che sono state reperite le informazioni per rendere utile la traccia dell'esecuzione va riprodotto il crash nell'applicazione. La finestra di dialogo di KDE apparirà qualche istante dopo al crash dell'applicazione.

[[Image:Kde-crash-handler.png|center|300px|La finestra di dialogo dei crash di KDE]]

Ora la generazione del backtrace dovrebbe risultare molto più completa, ad esempio:

Using host libthread_db library "/lib/libthread_db.so.1".
[Thread debugging using libthread_db enabled]
[New Thread -1232783168 (LWP 7604)]
[KCrash handler]
#6 0x0806be76 in TreeMapItem::parent (this=0x0)
at /home/bram/KDE/kde3/kdeaddons/konq-plugins/fsview/treemap.h:285
#7 0x08065fea in TreeMapItemList::compareItems (this=0xbfec04a8, item1=0x0,
item2=0x0)
at /home/bram/KDE/kde3/kdeaddons/konq-plugins/fsview/treemap.cpp:720
#8 0xb7281619 in QGList::operator== () from /usr/qt/3/lib/libqt-mt.so.3
#9 0x0806d498 in QPtrList<TreeMapItem>::operator== (this=0xbfec04a8,
list=@0xbfec0468) at /usr/qt/3/include/qptrlist.h:74
#10 0x08062e18 in TreeMapWidget::mousePressEvent (this=0xbfec03ac,
e=0xbfebff1c)
at /home/bram/KDE/kde3/kdeaddons/konq-plugins/fsview/treemap.cpp:1840
#11 0xb7004a63 in QWidget::event () from /usr/qt/3/lib/libqt-mt.so.3
#12 0xb6f6bca7 in QApplication::internalNotify ()
from /usr/qt/3/lib/libqt-mt.so.3
#13 0xb6f6ca88 in QApplication::notify () from /usr/qt/3/lib/libqt-mt.so.3
#14 0xb7725a84 in KApplication::notify (this=0xbfec055c, receiver=0xbfec03ac,
event=0xbfebff1c)
at /home/bram/KDE/kde3/kdelibs/kdecore/kapplication.cpp:550
#15 0xb6f0bfd2 in QETWidget::translateMouseEvent ()
from /usr/qt/3/lib/libqt-mt.so.3
#16 0xb6f0b8b0 in QApplication::x11ProcessEvent ()
from /usr/qt/3/lib/libqt-mt.so.3
#17 0xb6f1b761 in QEventLoop::processEvents () from /usr/qt/3/lib/libqt-mt.so.3
#18 0xb6f82831 in QEventLoop::enterLoop () from /usr/qt/3/lib/libqt-mt.so.3
#19 0xb6f826b6 in QEventLoop::exec () from /usr/qt/3/lib/libqt-mt.so.3
#20 0xb6f6b72f in QApplication::exec () from /usr/qt/3/lib/libqt-mt.so.3
#21 0x0805181e in main (argc=134673960, argv=0xffffffff)
at /home/bram/KDE/kde3/kdeaddons/konq-plugins/fsview/main.cpp:55

Molto meglio, vero? In questo backtrace sono presenti gli indirizzi di memoria, i file sorgenti, i numeri di riga e i parametri passati alle funzioni che hanno causato il problema. Ciò rende più facile per gli sviluppatori capire la causa del problema, in quanto sa dove guardare.

{{note|È '''obbligatorio''' avere GDB installato per ottenere il backtrace di un crash. Nella sezione seguente è spiegato cos'è GDB e come installarlo.}}

===Ottenere un backtrace con GDB===

In alcuni casi non è possibile creare un backtrace con la finestra di dialogo dei crash di KDE. Ciò può essere dovuto da un'applicazione entrata in un loop infinito, o dal fatto che la finestra del crash non è apparsa per qualche motivo. In tali casi è possibile ottenere un backtrace con <tt>gdb</tt>, il [http://sourceware.org/gdb/ Debugger GNU]. GDB è disponibile pacchettizzato per tutte le distribuzioni più importanti.

Il richiamo di GDB dipende dalle situazioni. È possibile sia eseguire un'applicazione all'interno di gdb che collegare gdb ad un processo già in esecuzione. Quest'ultima situazione in particolare è utile quando un'applicazione è già entrata in un loop infinito. Cominciamo con la prima soluzione; per eseguire un'applicazione da gdb digitare sulla riga di comando:

$ gdb someKDEapp

Apparirà il prompt di GDB. Per avviare l'applicazione, al momento non ancora avviata, è necessario invocare il comando<tt>run</tt>:

(gdb) run

{{note|Alcune applicazioni di KDE (ad esempio JuK e KTorrent) contengono del codice speciale per assicurarsi che ci sia una sola istanza dell'applicazione avviata alla volta. Per queste applicazioni è bisogna utilizzare il comando "run --nofork" al prompt di (gdb) invece di "run" perché altrimenti gdb proverebbe a debuggare il processo sbagliato. In caso di dubbio su quale usare è sufficiente provare ad avviare l'applicazione con l'opzione --nofork: se l'applicazione dice che è un'opzione sconosciuta è possibile rimuovere l'opzione --nofork.}}

Questo avvierà l'applicazione a cui siete abituati, e vi permetterà di lavorarci come fate solitamente (con la differenza che consumerà molta più memoria e potrebbe risultare molto più lenta). Ora va riprodotto il crash. Quando l'applicazione va in crash essa si chiuderà riportando al prompt di GDB. Ora è necessario invocare il comando 'backtrace':

(gdb) thread apply all backtrace

Ciò dovrebbe fornire una buona backtrace che può essere inserita nel Bugzilla di KDE.

In caso si voglia collegarsi ad un processo già esistente va invocato il seguente comando:

$ gdb someKDEapp pid

dove ''pid'' è il process ID del processo al quale ci si vuole collegare. Una volta collegati, quando il processo è in un ciclo infinito, dopo aver usato il comando 'backtrace' apparirà una traccia dell'esecuzione. È possibile utilizzare il comando 'continue' per lasciare l'applicazione eseguire nuovamente e premere Ctrl+C in gdb per poter inserire nuovamente dei comandi.

===Ottenere un backtrace con Valgrind===

Un altro strumento utile per creare backtrace di crash è [http://www.valgrind.org Valgrind]; esso non sostituisce GDB, ma piuttosto lo completa.

Quando si esegue un'applicazione in valgrind ogni pezzo di memoria letta o scritta dall'applicazione stessa viene controllato. Valgrind riporterà operazioni non valide in memoria nello standard output o in un file di log. Dato che la maggior parte dei crash sono dovuti a letture invalide in memoria, Valgrind può essere utile per tracciare dove succedono i problemi.

{{note|Valgrind consiste di vari tool per verificare o effettuare la profilazione di un'applicazione. In questo articolo useremo solo memcheck, il tool di default che viene chiamato all'esecuzione di valgrind.}}

Come GDB, Valgrind rende l'esecuzione delle applicazioni molto più lento e più esoso in termini di risorse.

Per avviare l'applicazione all'interno di valgrind:

$ valgrind --log-file=someKDEapp someKDEapp

Ora va riprodotto il crash. Appena avviene sia l'applicazione che valgrind termineranno. Ciò che rimane è un file con nome <tt>someKDEapp.pid</tt> dove ''pid'' sarà il process ID del processo valgrind. Il file potrebbe elencare più errori di quanti siano effettivamente causa del crash. Qui c'è un esempio della parte che causa il crash che corrisponde al backtrace GDB sopra:

==23292== Invalid read of size 4
==23292== at 0x806BD9E: TreeMapItem::parent() const (treemap.h:285)
==23292== by 0x8065FB9: TreeMapItemList::compareItems(void*, void*) (treemap.cpp:720)
==23292== by 0x50AC618: QGList::operator==(QGList const&) const (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== by 0x806D3BF: QPtrList<TreeMapItem>::operator==(QPtrList<TreeMapItem> const&) const (qptrlist.h:74)
==23292== by 0x8062DE7: TreeMapWidget::mousePressEvent(QMouseEvent*) (treemap.cpp:1840)
==23292== by 0x4E2FA62: QWidget::event(QEvent*) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== by 0x4D96CA6: QApplication::internalNotify(QObject*, QEvent*) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== by 0x4D97A87: QApplication::notify(QObject*, QEvent*) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== by 0x4809AC3: KApplication::notify(QObject*, QEvent*) (kapplication.cpp:550)
==23292== by 0x4D36FD1: QETWidget::translateMouseEvent(_XEvent const*) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== by 0x4D368AF: QApplication::x11ProcessEvent(_XEvent*) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== by 0x4D46760: QEventLoop::processEvents(unsigned) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== Address 0x2C is not stack'd, malloc'd or (recently) free'd

Per essere sicuro allega alla segnalazione del bug l'intero file log fornito da valgrind.

Development/Tutorials/Debugging/How to create useful crash reports (it)

2010-06-02T14:15:07Z

Panda84: Sezioni "crash" e "gdb" tradotte.

{{Template:I18n/Language Navigation Bar|Development/Tutorials/Debugging/How to create useful crash reports}}

== Introduzione ==

Questo documento descrive come riprodurre un backtrace (ovvero una "traccia dell'esecuzione") di applicazioni KDE che vanno in crash. Inizialmente vengono fornite alcune informazioni generali; nel seguito vengono descritte le procedure per ottenere i pacchetti KDE per varie distribuzioni utili a ottenere i backtrace. Queste parti dovrebbero essere sufficienti per la maggior parte della gente. Ci sono alcune sezioni addizionali su come creare backtrace con il GNU Debugger e con Valgrind, che possono essere utili in alcuni casi.

== Come creare segnalazioni di crash utili ==

Una buona segnalazione di bug nel [http://bugs.kde.org Bugzilla] consiste di due parti: una '''descrizione''' di come riprodurre il crash ed un '''backtrace''' del crash stesso. Se manca uno di questi elementi risulta molto più difficile, se non impossibile, per gli sviluppatori affrontare il problema.

Una descrizione deve consistere di qualcosa più di un solo "si è piantato". È necessario cercare di descrivere qualsiasi cosa venga fatta prima del crash. È stato cliccato su un pulsante, aperto un particolare sito o file che ha causato il problema? Quel piccolo dettaglio che potrebbe sembrare inutile all'utente potrebbe risultare utile allo sviluppatore, quindi è sempre il caso di annotarlo nella segnalazione.

Un articolo approfondito su come scrivere delle buone descrizioni di bug e segnalazioni è disponibile a [http://www.chiark.greenend.org.uk/~sgtatham/bugs.html questo indirizzo], è caldamente consigliato leggerlo prima di effettuare delle segnalazioni.

Il backtrace di un crash non va allegato alla segnalazione; va semplicemente incollato in coda al testo della segnalazione stessa. In questo modo è molto più semplice per gli sviluppatori individuare segnalazioni duplicate dello stesso bug, in quanto la ricerca non avviene anche sul testo degli allegati.

Se si incolla un backtrace in una segnalazione assicurarsi di rimuovere tutte le righe, eccetto un paio, del tipo:

(no debugging symbols found)

dal backtrace, in quanto lo rendono più difficile da leggere.

Sebbene incollare backtrace direttamente sia preferibile rispetto ad aggiungere un allegato, non vanno incollate altre cose come log (valgrind, strace o output del terminale) o esempi di dati (email, file HTML e così via); per queste cose vanno usati gli allegati.

=== Backtrace ===

I backtrace sono essenziali. Possono sembrare senza significato per i non addetti, ma in realtà possono contenere una gran quantità di informazioni utili. Un backtrace descrive quali funzioni sono state chiamate prima del crash, in modo che gli sviluppatori possano tracciare in quale metodo è partito il problema. Ottenere buoni backtrace ha uno svantaggio: [[Development/Tutorials/Debugging/Debugging_symbols|le librerie e gli eseguibili occupano molto più spazio rispetto alla versione ottimizzata]]. È per questo motivo che molte distribuzioni scelgono di intallare file senza simboli di debugging, '''che causa la creazione di backtrace inutili":

(no debugging symbols found)
Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread -1233848624 (LWP 12212)]
[New Thread -1255081072 (LWP 12820)]
[New Thread -1240921200 (LWP 12819)]
[New Thread -1266680944 (LWP 12818)]
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
0xffffe410 in __kernel_vsyscall ()
#0 0xffffe410 in __kernel_vsyscall ()
#1 0xb6a1210b in ?? () from /lib/tls/i686/cmov/libpthread.so.0
#2 0xb6a85afe in ?? () from /usr/lib/libX11.so.6
#3 0x00000003 in ?? ()
#4 0x082149c0 in ?? ()
#5 0x00003ffc in ?? ()
#6 0x00000000 in ?? ()

Per fortuna non c'è da preoccuparsi, con alcune modifiche è possibile creare backtrace con tutte le informazioni necessarie per le applicazioni KDE.

=== Preparare i pacchetti KDE ===

Se la tua distribuzione ha pacchetti predisposti per il debugging è necessario installarli.

È facile vedere quali pacchetti di debug manchino guardando al backtrace. Prendiamo in considerazione la seguente linea di una backtrace:

#6 0xb7975bdc in ?? () from /usr/lib/libkmailprivate.so.4

Il simbolo <tt>??</tt> indica che la libreria <tt>libkmailprivate.so.4</tt> è priva di informazioni di debug, che potrebbero essere disponibili in pacchetti di debug separati. In questo caso, è facile capire che è necessario installare i pacchetti di debug per KMail per ottenere un backtrace migliore.

Alcune volte, c'è bisogno di installare più di un pacchetto di debug per ottenere un buon backtrace. Ciò dipende da come le distribuzioni suddividono i pacchetti. Per esempio, per alcune distribuzioni è sufficiente installare il pacchetto per <tt>kdepim</tt> per avere sufficienti informazioni riguardo un crash in KMail, in altre distribuzioni c'è un pacchetto di debug aggiuntivo per KMail.

Qui c'è una lista di come ottenere i pacchetti di debug per alcune distribuzioni:

*'''Debian''' - Debian offre pacchetti <tt>-dbg</tt> per creare facilmente backtrace utili. Basta installare il corrispondente pacchetto <tt>-dbg</tt>. ad esempio <tt>kdepim-dbg</tt> per i crash di KMail. Le dipendenze di -dbg assicurano di ottenere anche gli altri pacchetti necessari (kdelibs-dbg, gdb, e così via).
*'''FreeBSD ports''' - Fare riferimento alla pagina [http://freebsd.kde.org/faq.php#AKDEapplicationcrashedandIwanttofileabugreportathttpbugskdeorgbutthebacktraceintheKDECrashManagerisuselessWhatcanIdo delle FAQ di KDE su FreeBSD].
*'''Gentoo''' - Gentoo ha [http://www.gentoo.org/proj/en/qa/backtraces.xml una guida] che descrive come procedere.
*'''Mandriva''' - A partire da Mandriva 2007.0 in su ci sono pacchetti addizionali per tutto KDE. È sufficiente installare il corrispondente pacchetto <tt>-debug</tt>, come <tt>kdebase-debug</tt> e <tt>kdemultimedia-debug</tt>. Quasi certamente va installato <tt>kdelibs-debug</tt> in ogni caso.
** Nota: i pacchetti <tt>-debug</tt> sono in repository separati. Ad esempio, per tutti i pacchetti in <tt>main</tt>, si possono trovare i pacchetti di debug nel repository <tt>debug_main</tt>.
*'''Kubuntu/Ubuntu''' - La famiglia di distribuzioni Ubuntu rende le cose abbastanza facili. Ogni modulo ufficiale di KDE ha un pacchetto aggiuntivo nei repository con il suffisso <tt>-dbg</tt>. È importante installare sempre <tt>kdelibs5-dbg</tt>, in quanto tutte le applicazioni KDE usano kdelibs (kdelibs-dbg per applicazioni KDE 3). Oltre a ciò è necessario installare il pacchetto -dbg anche per l'applicazione che è andata in crash. Per esempio se si è piantato KOrganizer è necessario installare anche <tt>kdepim-dbg</tt>. Se il programma non fa parte di un modulo ufficiale di KDE e non ha un apposito pacchetto -dbg, è possibile installare il pacchetto -dbgsym dal repository in questa [https://wiki.kubuntu.org/DebuggingProgramCrash pagina sul debugging dei programmi].
** Durante il ciclo di sviluppo di Ubuntu il gestore di crash Apport è attivo e si preoccuperà di riportare i crash a launchpad.net e creare il backtrace per te. Se si desidera utilizzare il gestore dei crash di KDE è possibile disabilitarlo nel file /etc/defaults/apport
** A partire da Lucid Lynx (10.04) Kubuntu inoltrerà tutti i bug che non sono peculiari della distribuzione al sistema di gestione di KDE; Apport è ora disabilitato in modo da utilizzare DrKonqui come gestore predefinito dei crash.
*'''openSUSE''' - È necessario solo installare i pacchetti <tt>-debuginfo</tt>, ad esempio: <tt>kdepimlibs4-debuginfo</tt>. È possibile trovare questi pacchetti nei [http://en.opensuse.org/KDE/Repositories repository KDE]. C'è anche una [http://en.opensuse.org/Bugs:An_application_crashed pagina dedicata al debugging in openSUSE].
*'''Fedora''' - In Fedora è sufficiente utilizzare i seguenti comandi:
*# <tt>yum provides "/usr/lib/libkmailprivate.so.4"</tt> per trovare quale pacchetto fornisce quel file;
*# <tt>debuginfo-install kdepim</tt> da utente root per installare i pacchetti di debug per quel pacchetto (dipendenze incluse).
*: Una guida completa e dettagliata per Fedora è disponibile in [http://fedoraproject.org/wiki/StackTraces questo documento] che descrive come procedere. Fedora utilizza un repository debuginfo separato che va abilitato. Si consiglia anche di utilizzare il plugin yum <tt>auto-update-debug-info</tt> per tenere aggiornati i pacchetti debuginfo.

Nel raro caso in cui la distribuzione non abbia pacchetti di contenente i simboli di debug per KDE, è necessario compilare KDE dai sorgenti:

* Nel caso di KDE 3, al passo di configure, è necessario passare il parametro <tt>--enable-debug=full</tt> al fine di creare i simboli di debug nei file risultanti.
* Nel caso di KDE 4, al passo di cmake, è necessario passare il parametro <tt>-DCMAKE_BUILD_TYPE=debugfull</tt>. Se si vuole passare opzioni personalizzate a CXXFLAGS, utilizzare <tt>-DCMAKE_BUILD_TYPE=None CMAKE_CXX_FLAGS="-O0 -g"</tt>. È possibile cambiare le opzioni CMAKE_CXX_FLAGS in base alle proprie necessità.

Dopodiché è sufficiente dare <tt>make</tt> e <tt>make install</tt> come al solito.

===Crash!===

Ora che sono state reperite le informazioni per rendere utile la traccia dell'esecuzione va riprodotto il crash nell'applicazione. La finestra di dialogo di KDE apparirà qualche istante dopo al crash dell'applicazione.

[[Image:Kde-crash-handler.png|center|300px|La finestra di dialogo dei crash di KDE]]

Ora la generazione del backtrace dovrebbe risultare molto più completa, ad esempio:

Using host libthread_db library "/lib/libthread_db.so.1".
[Thread debugging using libthread_db enabled]
[New Thread -1232783168 (LWP 7604)]
[KCrash handler]
#6 0x0806be76 in TreeMapItem::parent (this=0x0)
at /home/bram/KDE/kde3/kdeaddons/konq-plugins/fsview/treemap.h:285
#7 0x08065fea in TreeMapItemList::compareItems (this=0xbfec04a8, item1=0x0,
item2=0x0)
at /home/bram/KDE/kde3/kdeaddons/konq-plugins/fsview/treemap.cpp:720
#8 0xb7281619 in QGList::operator== () from /usr/qt/3/lib/libqt-mt.so.3
#9 0x0806d498 in QPtrList<TreeMapItem>::operator== (this=0xbfec04a8,
list=@0xbfec0468) at /usr/qt/3/include/qptrlist.h:74
#10 0x08062e18 in TreeMapWidget::mousePressEvent (this=0xbfec03ac,
e=0xbfebff1c)
at /home/bram/KDE/kde3/kdeaddons/konq-plugins/fsview/treemap.cpp:1840
#11 0xb7004a63 in QWidget::event () from /usr/qt/3/lib/libqt-mt.so.3
#12 0xb6f6bca7 in QApplication::internalNotify ()
from /usr/qt/3/lib/libqt-mt.so.3
#13 0xb6f6ca88 in QApplication::notify () from /usr/qt/3/lib/libqt-mt.so.3
#14 0xb7725a84 in KApplication::notify (this=0xbfec055c, receiver=0xbfec03ac,
event=0xbfebff1c)
at /home/bram/KDE/kde3/kdelibs/kdecore/kapplication.cpp:550
#15 0xb6f0bfd2 in QETWidget::translateMouseEvent ()
from /usr/qt/3/lib/libqt-mt.so.3
#16 0xb6f0b8b0 in QApplication::x11ProcessEvent ()
from /usr/qt/3/lib/libqt-mt.so.3
#17 0xb6f1b761 in QEventLoop::processEvents () from /usr/qt/3/lib/libqt-mt.so.3
#18 0xb6f82831 in QEventLoop::enterLoop () from /usr/qt/3/lib/libqt-mt.so.3
#19 0xb6f826b6 in QEventLoop::exec () from /usr/qt/3/lib/libqt-mt.so.3
#20 0xb6f6b72f in QApplication::exec () from /usr/qt/3/lib/libqt-mt.so.3
#21 0x0805181e in main (argc=134673960, argv=0xffffffff)
at /home/bram/KDE/kde3/kdeaddons/konq-plugins/fsview/main.cpp:55

Molto meglio, vero? In questo backtrace sono presenti gli indirizzi di memoria, i file sorgenti, i numeri di riga e i parametri passati alle funzioni che hanno causato il problema. Ciò rende più facile per gli sviluppatori capire la causa del problema, in quanto sa dove guardare.

{{note|È '''obbligatorio''' avere GDB installato per ottenere il backtrace di un crash. Nella sezione seguente è spiegato cos'è GDB e come installarlo.}}

===Ottenere un backtrace con GDB===

In alcuni casi non è possibile creare un backtrace con la finestra di dialogo dei crash di KDE. Ciò può essere dovuto da un'applicazione entrata in un loop infinito, o dal fatto che la finestra del crash non è apparsa per qualche motivo. In tali casi è possibile ottenere un backtrace con <tt>gdb</tt>, il [http://sourceware.org/gdb/ Debugger GNU]. GDB è disponibile pacchettizzato per tutte le distribuzioni più importanti.

Il richiamo di GDB dipende dalle situazioni. È possibile sia eseguire un'applicazione all'interno di gdb che collegare gdb ad un processo già in esecuzione. Quest'ultima situazione in particolare è utile quando un'applicazione è già entrata in un loop infinito. Cominciamo con la prima soluzione; per eseguire un'applicazione da gdb digitare sulla riga di comando:

$ gdb someKDEapp

Apparirà il prompt di GDB. Per avviare l'applicazione, al momento non ancora avviata, è necessario invocare il comando<tt>run</tt>:

(gdb) run

{{note|Alcune applicazioni di KDE (ad esempio JuK e KTorrent) contengono del codice speciale per assicurarsi che ci sia una sola istanza dell'applicazione avviata alla volta. Per queste applicazioni è bisogna utilizzare il comando "run --nofork" al prompt di (gdb) invece di "run" perché altrimenti gdb proverebbe a debuggare il processo sbagliato. In caso di dubbio su quale usare è sufficiente provare ad avviare l'applicazione con l'opzione --nofork: se l'applicazione dice che è un'opzione sconosciuta è possibile rimuovere l'opzione --nofork.}}

Questo avvierà l'applicazione a cui siete abituati, e vi permetterà di lavorarci come fate solitamente (con la differenza che consumerà molta più memoria e potrebbe risultare molto più lenta). Ora va riprodotto il crash. Quando l'applicazione va in crash essa si chiuderà riportando al prompt di GDB. Ora è necessario invocare il comando 'backtrace':

(gdb) thread apply all backtrace

Ciò dovrebbe fornire una buona backtrace che può essere inserita nel Bugzilla di KDE.

In caso si voglia collegarsi ad un processo già esistente va invocato il seguente comando:

$ gdb someKDEapp pid

dove ''pid'' è il process ID del processo al quale ci si vuole collegare. Una volta collegati, quando il processo è in un ciclo infinito, dopo aver usato il comando 'backtrace' apparirà una traccia dell'esecuzione. È possibile utilizzare il comando 'continue' per lasciare l'applicazione eseguire nuovamente e premere Ctrl+C in gdb per poter inserire nuovamente dei comandi.

===Retrieving a backtrace with Valgrind===

When it comes to crashes, [http://www.valgrind.org Valgrind] is also a useful tool to create a backtrace. It's not a substitution for GDB, but rather a supplement.

When you run an application in valgrind, every piece of memory read or written by the application is being checked. Valgrind will report erroneous memory operations in the standard output or in a log file. Since most crashes are due to an invalid memory read, valgrind can be useful to track down where the problem occurs.

{{note|Valgrind consists of several tools in order to check or profile an application. For this article, we only use memcheck, the default tool when valgrind is being invoked.}}

Like GDB, Valgrind makes running an application much slower, while consuming a lot more resources.

Start the application within valgrind:

$ valgrind --log-file=someKDEapp someKDEapp

Now reproduce the crash. As soon as this happens, the application and valgrind will terminate. What's left is a file named <tt>someKDEapp.pid</tt> where ''pid'' is replaced by the process ID of the valgrind process. The file may list more errors than the one causing the crash. Here's the bit causing the crash which corresponds to the GDB backtrace above:

==23292== Invalid read of size 4
==23292== at 0x806BD9E: TreeMapItem::parent() const (treemap.h:285)
==23292== by 0x8065FB9: TreeMapItemList::compareItems(void*, void*) (treemap.cpp:720)
==23292== by 0x50AC618: QGList::operator==(QGList const&) const (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== by 0x806D3BF: QPtrList<TreeMapItem>::operator==(QPtrList<TreeMapItem> const&) const (qptrlist.h:74)
==23292== by 0x8062DE7: TreeMapWidget::mousePressEvent(QMouseEvent*) (treemap.cpp:1840)
==23292== by 0x4E2FA62: QWidget::event(QEvent*) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== by 0x4D96CA6: QApplication::internalNotify(QObject*, QEvent*) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== by 0x4D97A87: QApplication::notify(QObject*, QEvent*) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== by 0x4809AC3: KApplication::notify(QObject*, QEvent*) (kapplication.cpp:550)
==23292== by 0x4D36FD1: QETWidget::translateMouseEvent(_XEvent const*) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== by 0x4D368AF: QApplication::x11ProcessEvent(_XEvent*) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== by 0x4D46760: QEventLoop::processEvents(unsigned) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== Address 0x2C is not stack'd, malloc'd or (recently) free'd

But to be sure, just attach the whole log file to the crash report.

Development/Tutorials/Debugging/How to create useful crash reports (it)

2010-06-02T13:28:26Z

Panda84: Completata la sezione "Preparare i pacchetti"

{{Template:I18n/Language Navigation Bar|Development/Tutorials/Debugging/How to create useful crash reports}}

== Introduzione ==

Questo documento descrive come riprodurre un backtrace (ovvero una "traccia dell'esecuzione") di applicazioni KDE che vanno in crash. Inizialmente vengono fornite alcune informazioni generali; nel seguito vengono descritte le procedure per ottenere i pacchetti KDE per varie distribuzioni utili a ottenere i backtrace. Queste parti dovrebbero essere sufficienti per la maggior parte della gente. Ci sono alcune sezioni addizionali su come creare backtrace con il GNU Debugger e con Valgrind, che possono essere utili in alcuni casi.

== Come creare segnalazioni di crash utili ==

Una buona segnalazione di bug nel [http://bugs.kde.org Bugzilla] consiste di due parti: una '''descrizione''' di come riprodurre il crash ed un '''backtrace''' del crash stesso. Se manca uno di questi elementi risulta molto più difficile, se non impossibile, per gli sviluppatori affrontare il problema.

Una descrizione deve consistere di qualcosa più di un solo "si è piantato". È necessario cercare di descrivere qualsiasi cosa venga fatta prima del crash. È stato cliccato su un pulsante, aperto un particolare sito o file che ha causato il problema? Quel piccolo dettaglio che potrebbe sembrare inutile all'utente potrebbe risultare utile allo sviluppatore, quindi è sempre il caso di annotarlo nella segnalazione.

Un articolo approfondito su come scrivere delle buone descrizioni di bug e segnalazioni è disponibile a [http://www.chiark.greenend.org.uk/~sgtatham/bugs.html questo indirizzo], è caldamente consigliato leggerlo prima di effettuare delle segnalazioni.

Il backtrace di un crash non va allegato alla segnalazione; va semplicemente incollato in coda al testo della segnalazione stessa. In questo modo è molto più semplice per gli sviluppatori individuare segnalazioni duplicate dello stesso bug, in quanto la ricerca non avviene anche sul testo degli allegati.

Se si incolla un backtrace in una segnalazione assicurarsi di rimuovere tutte le righe, eccetto un paio, del tipo:

(no debugging symbols found)

dal backtrace, in quanto lo rendono più difficile da leggere.

Sebbene incollare backtrace direttamente sia preferibile rispetto ad aggiungere un allegato, non vanno incollate altre cose come log (valgrind, strace o output del terminale) o esempi di dati (email, file HTML e così via); per queste cose vanno usati gli allegati.

=== Backtrace ===

I backtrace sono essenziali. Possono sembrare senza significato per i non addetti, ma in realtà possono contenere una gran quantità di informazioni utili. Un backtrace descrive quali funzioni sono state chiamate prima del crash, in modo che gli sviluppatori possano tracciare in quale metodo è partito il problema. Ottenere buoni backtrace ha uno svantaggio: [[Development/Tutorials/Debugging/Debugging_symbols|le librerie e gli eseguibili occupano molto più spazio rispetto alla versione ottimizzata]]. È per questo motivo che molte distribuzioni scelgono di intallare file senza simboli di debugging, '''che causa la creazione di backtrace inutili":

(no debugging symbols found)
Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread -1233848624 (LWP 12212)]
[New Thread -1255081072 (LWP 12820)]
[New Thread -1240921200 (LWP 12819)]
[New Thread -1266680944 (LWP 12818)]
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
0xffffe410 in __kernel_vsyscall ()
#0 0xffffe410 in __kernel_vsyscall ()
#1 0xb6a1210b in ?? () from /lib/tls/i686/cmov/libpthread.so.0
#2 0xb6a85afe in ?? () from /usr/lib/libX11.so.6
#3 0x00000003 in ?? ()
#4 0x082149c0 in ?? ()
#5 0x00003ffc in ?? ()
#6 0x00000000 in ?? ()

Per fortuna non c'è da preoccuparsi, con alcune modifiche è possibile creare backtrace con tutte le informazioni necessarie per le applicazioni KDE.

=== Preparare i pacchetti KDE ===

Se la tua distribuzione ha pacchetti predisposti per il debugging è necessario installarli.

È facile vedere quali pacchetti di debug manchino guardando al backtrace. Prendiamo in considerazione la seguente linea di una backtrace:

#6 0xb7975bdc in ?? () from /usr/lib/libkmailprivate.so.4

Il simbolo <tt>??</tt> indica che la libreria <tt>libkmailprivate.so.4</tt> è priva di informazioni di debug, che potrebbero essere disponibili in pacchetti di debug separati. In questo caso, è facile capire che è necessario installare i pacchetti di debug per KMail per ottenere un backtrace migliore.

Alcune volte, c'è bisogno di installare più di un pacchetto di debug per ottenere un buon backtrace. Ciò dipende da come le distribuzioni suddividono i pacchetti. Per esempio, per alcune distribuzioni è sufficiente installare il pacchetto per <tt>kdepim</tt> per avere sufficienti informazioni riguardo un crash in KMail, in altre distribuzioni c'è un pacchetto di debug aggiuntivo per KMail.

Qui c'è una lista di come ottenere i pacchetti di debug per alcune distribuzioni:

*'''Debian''' - Debian offre pacchetti <tt>-dbg</tt> per creare facilmente backtrace utili. Basta installare il corrispondente pacchetto <tt>-dbg</tt>. ad esempio <tt>kdepim-dbg</tt> per i crash di KMail. Le dipendenze di -dbg assicurano di ottenere anche gli altri pacchetti necessari (kdelibs-dbg, gdb, e così via).
*'''FreeBSD ports''' - Fare riferimento alla pagina [http://freebsd.kde.org/faq.php#AKDEapplicationcrashedandIwanttofileabugreportathttpbugskdeorgbutthebacktraceintheKDECrashManagerisuselessWhatcanIdo delle FAQ di KDE su FreeBSD].
*'''Gentoo''' - Gentoo ha [http://www.gentoo.org/proj/en/qa/backtraces.xml una guida] che descrive come procedere.
*'''Mandriva''' - A partire da Mandriva 2007.0 in su ci sono pacchetti addizionali per tutto KDE. È sufficiente installare il corrispondente pacchetto <tt>-debug</tt>, come <tt>kdebase-debug</tt> e <tt>kdemultimedia-debug</tt>. Quasi certamente va installato <tt>kdelibs-debug</tt> in ogni caso.
** Nota: i pacchetti <tt>-debug</tt> sono in repository separati. Ad esempio, per tutti i pacchetti in <tt>main</tt>, si possono trovare i pacchetti di debug nel repository <tt>debug_main</tt>.
*'''Kubuntu/Ubuntu''' - La famiglia di distribuzioni Ubuntu rende le cose abbastanza facili. Ogni modulo ufficiale di KDE ha un pacchetto aggiuntivo nei repository con il suffisso <tt>-dbg</tt>. È importante installare sempre <tt>kdelibs5-dbg</tt>, in quanto tutte le applicazioni KDE usano kdelibs (kdelibs-dbg per applicazioni KDE 3). Oltre a ciò è necessario installare il pacchetto -dbg anche per l'applicazione che è andata in crash. Per esempio se si è piantato KOrganizer è necessario installare anche <tt>kdepim-dbg</tt>. Se il programma non fa parte di un modulo ufficiale di KDE e non ha un apposito pacchetto -dbg, è possibile installare il pacchetto -dbgsym dal repository in questa [https://wiki.kubuntu.org/DebuggingProgramCrash pagina sul debugging dei programmi].
** Durante il ciclo di sviluppo di Ubuntu il gestore di crash Apport è attivo e si preoccuperà di riportare i crash a launchpad.net e creare il backtrace per te. Se si desidera utilizzare il gestore dei crash di KDE è possibile disabilitarlo nel file /etc/defaults/apport
** A partire da Lucid Lynx (10.04) Kubuntu inoltrerà tutti i bug che non sono peculiari della distribuzione al sistema di gestione di KDE; Apport è ora disabilitato in modo da utilizzare DrKonqui come gestore predefinito dei crash.
*'''openSUSE''' - È necessario solo installare i pacchetti <tt>-debuginfo</tt>, ad esempio: <tt>kdepimlibs4-debuginfo</tt>. È possibile trovare questi pacchetti nei [http://en.opensuse.org/KDE/Repositories repository KDE]. C'è anche una [http://en.opensuse.org/Bugs:An_application_crashed pagina dedicata al debugging in openSUSE].
*'''Fedora''' - In Fedora è sufficiente utilizzare i seguenti comandi:
*# <tt>yum provides "/usr/lib/libkmailprivate.so.4"</tt> per trovare quale pacchetto fornisce quel file;
*# <tt>debuginfo-install kdepim</tt> da utente root per installare i pacchetti di debug per quel pacchetto (dipendenze incluse).
*: Una guida completa e dettagliata per Fedora è disponibile in [http://fedoraproject.org/wiki/StackTraces questo documento] che descrive come procedere. Fedora utilizza un repository debuginfo separato che va abilitato. Si consiglia anche di utilizzare il plugin yum <tt>auto-update-debug-info</tt> per tenere aggiornati i pacchetti debuginfo.

Nel raro caso in cui la distribuzione non abbia pacchetti di contenente i simboli di debug per KDE, è necessario compilare KDE dai sorgenti:

* Nel caso di KDE 3, al passo di configure, è necessario passare il parametro <tt>--enable-debug=full</tt> al fine di creare i simboli di debug nei file risultanti.
* Nel caso di KDE 4, al passo di cmake, è necessario passare il parametro <tt>-DCMAKE_BUILD_TYPE=debugfull</tt>. Se si vuole passare opzioni personalizzate a CXXFLAGS, utilizzare <tt>-DCMAKE_BUILD_TYPE=None CMAKE_CXX_FLAGS="-O0 -g"</tt>. È possibile cambiare le opzioni CMAKE_CXX_FLAGS in base alle proprie necessità.

Dopodiché è sufficiente dare <tt>make</tt> e <tt>make install</tt> come al solito.

===Crash!===

Now it's time to crash your application. The KDE Crash Dialog should appear right after the crash, which shows the Backtrace tab.

[[Image:Kde-crash-handler.png|center|300px|KDE Crash Dialog]]

Click that tab and wait for a minute. This process may take quite some memory, so things may go sluggish all of a sudden. But the result should look much better. For example:

Using host libthread_db library "/lib/libthread_db.so.1".
[Thread debugging using libthread_db enabled]
[New Thread -1232783168 (LWP 7604)]
[KCrash handler]
#6 0x0806be76 in TreeMapItem::parent (this=0x0)
at /home/bram/KDE/kde3/kdeaddons/konq-plugins/fsview/treemap.h:285
#7 0x08065fea in TreeMapItemList::compareItems (this=0xbfec04a8, item1=0x0,
item2=0x0)
at /home/bram/KDE/kde3/kdeaddons/konq-plugins/fsview/treemap.cpp:720
#8 0xb7281619 in QGList::operator== () from /usr/qt/3/lib/libqt-mt.so.3
#9 0x0806d498 in QPtrList<TreeMapItem>::operator== (this=0xbfec04a8,
list=@0xbfec0468) at /usr/qt/3/include/qptrlist.h:74
#10 0x08062e18 in TreeMapWidget::mousePressEvent (this=0xbfec03ac,
e=0xbfebff1c)
at /home/bram/KDE/kde3/kdeaddons/konq-plugins/fsview/treemap.cpp:1840
#11 0xb7004a63 in QWidget::event () from /usr/qt/3/lib/libqt-mt.so.3
#12 0xb6f6bca7 in QApplication::internalNotify ()
from /usr/qt/3/lib/libqt-mt.so.3
#13 0xb6f6ca88 in QApplication::notify () from /usr/qt/3/lib/libqt-mt.so.3
#14 0xb7725a84 in KApplication::notify (this=0xbfec055c, receiver=0xbfec03ac,
event=0xbfebff1c)
at /home/bram/KDE/kde3/kdelibs/kdecore/kapplication.cpp:550
#15 0xb6f0bfd2 in QETWidget::translateMouseEvent ()
from /usr/qt/3/lib/libqt-mt.so.3
#16 0xb6f0b8b0 in QApplication::x11ProcessEvent ()
from /usr/qt/3/lib/libqt-mt.so.3
#17 0xb6f1b761 in QEventLoop::processEvents () from /usr/qt/3/lib/libqt-mt.so.3
#18 0xb6f82831 in QEventLoop::enterLoop () from /usr/qt/3/lib/libqt-mt.so.3
#19 0xb6f826b6 in QEventLoop::exec () from /usr/qt/3/lib/libqt-mt.so.3
#20 0xb6f6b72f in QApplication::exec () from /usr/qt/3/lib/libqt-mt.so.3
#21 0x0805181e in main (argc=134673960, argv=0xffffffff)
at /home/bram/KDE/kde3/kdeaddons/konq-plugins/fsview/main.cpp:55

This looks better, right? It shows memory addresses, the source files and line numbers and the parameters passed to functions. Which make it more helpful to the developer where to look for the problem.

{{note|You '''need''' GDB installed to get the backtrace of a crash. Please read the next section to know what GDB is, and how to install it.}}

===Retrieving a backtrace with GDB===

In some cases, it is not possible to create a backtrace with the KDE Crash Dialog. This may be caused by an application which entered an infinite loop, or the crash dialog did not appear at all for some reason. You can try to grab a backtrace with <tt>gdb</tt>, the [http://sourceware.org/gdb/ GNU Debugger]. GDB is widely available through distribution packages.

Invoking GDB differs from the situation. You can run an application from inside gdb, or attach gdb to an already running process. The latter may be useful when an application already has entered an infinite loop. But we will first start with running an application inside gdb. From the shell, run:

$ gdb someKDEapp

The GDB prompt will appear. Note that this does not start the application itself, you should run it by invoking the <tt>run</tt> command:

(gdb) run

This will run the application like you are used to, and you can work with it like normal (it only consumes far more memory and may feel sluggish). Now it's time to reproduce your crash. When you succeed, the application just closes and you should return to your GDB prompt. Now it's time to run the 'backtrace' command:

{{note|Some KDE applications (such as JuK and KTorrent) have special code to ensure that there is only one running instance of the application at a time. For these applications you should type in "run --nofork" at the (gdb) prompt instead of "run" because otherwise gdb will try to debug the wrong process. If you are unsure as to whether to use --nofork just try it. If the application says it's an unknown option you can remove --nofork.}}

(gdb) thread apply all backtrace

This should give a good backtrace which can be posted at the KDE Bugzilla.

In case you want to attach to an existing process, run the following command in the shell:

$ gdb someKDEapp pid

where ''pid'' is the process ID of the process you want to attach to. Once attached, and the process is in an infinite loop, after using the 'backtrace' command again a useful backtrace will appear. You can use 'continue' command to let the application run again and press Ctrl+C in gdb to be able to again enter commands.

===Retrieving a backtrace with Valgrind===

When it comes to crashes, [http://www.valgrind.org Valgrind] is also a useful tool to create a backtrace. It's not a substitution for GDB, but rather a supplement.

When you run an application in valgrind, every piece of memory read or written by the application is being checked. Valgrind will report erroneous memory operations in the standard output or in a log file. Since most crashes are due to an invalid memory read, valgrind can be useful to track down where the problem occurs.

{{note|Valgrind consists of several tools in order to check or profile an application. For this article, we only use memcheck, the default tool when valgrind is being invoked.}}

Like GDB, Valgrind makes running an application much slower, while consuming a lot more resources.

Start the application within valgrind:

$ valgrind --log-file=someKDEapp someKDEapp

Now reproduce the crash. As soon as this happens, the application and valgrind will terminate. What's left is a file named <tt>someKDEapp.pid</tt> where ''pid'' is replaced by the process ID of the valgrind process. The file may list more errors than the one causing the crash. Here's the bit causing the crash which corresponds to the GDB backtrace above:

==23292== Invalid read of size 4
==23292== at 0x806BD9E: TreeMapItem::parent() const (treemap.h:285)
==23292== by 0x8065FB9: TreeMapItemList::compareItems(void*, void*) (treemap.cpp:720)
==23292== by 0x50AC618: QGList::operator==(QGList const&) const (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== by 0x806D3BF: QPtrList<TreeMapItem>::operator==(QPtrList<TreeMapItem> const&) const (qptrlist.h:74)
==23292== by 0x8062DE7: TreeMapWidget::mousePressEvent(QMouseEvent*) (treemap.cpp:1840)
==23292== by 0x4E2FA62: QWidget::event(QEvent*) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== by 0x4D96CA6: QApplication::internalNotify(QObject*, QEvent*) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== by 0x4D97A87: QApplication::notify(QObject*, QEvent*) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== by 0x4809AC3: KApplication::notify(QObject*, QEvent*) (kapplication.cpp:550)
==23292== by 0x4D36FD1: QETWidget::translateMouseEvent(_XEvent const*) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== by 0x4D368AF: QApplication::x11ProcessEvent(_XEvent*) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== by 0x4D46760: QEventLoop::processEvents(unsigned) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== Address 0x2C is not stack'd, malloc'd or (recently) free'd

But to be sure, just attach the whole log file to the crash report.

Development/Tutorials/Debugging/How to create useful crash reports

2010-05-15T15:37:35Z

Panda84: Better clarity in Ubuntu section.

{{Template:I18n/Language Navigation Bar|Development/Tutorials/Debugging/How to create useful crash reports}}
==Introduction==

This document describes how to reproduce a useful backtrace of crashing KDE applications. First, some general information is given. Then, we will describe for several distributions how to prepare your KDE packages and gaining the backtrace. This should be enough for most people.
There are additional sections on how to create backtraces with the GNU Debugger and with Valgrind, which are in some cases useful.

==How to create useful crash reports==

A good crash report at [http://bugs.kde.org Bugzilla] consists of two parts: a '''description''' of how to reproduce the crash and a '''backtrace''' of the crash. With one of those elements missing, it is much harder (if not impossible) for developers to tackle the problem.

A description should consist of more than only "it crashed". Try to describe everything you did prior to the crash. Did you click on a button, opened a particular website or file which caused problems? That little detail which may look useless to you may be useful for the developer, so just write it down.

A more insightful article on how to write good bug descriptions is available [http://www.chiark.greenend.org.uk/~sgtatham/bugs.html at this link], please read that before reporting bugs.

Don't attach the backtrace to the bug report. Instead, simply paste it. This way it is much easier for developers to search for duplicate reports, because attachments will not be searched.

If you paste a backtrace to a report, make sure you strip all but one or two of the
(no debugging symbols found)
lines from the backtrace as they make it harder to read.

Even though pasting backtraces directly is preferred over adding an attachment, please do not paste other things like logs (valgrind, strace or terminal output) or example data (mails, HTML files and so on). Use attachments for these items.

===Backtraces===

Backtraces are essential. They may look meaningless to you, but they might actually contain a wealth of useful information. A backtrace describes which functions were called prior to the crash, so that developers may track down in which function the mess started. Having good backtraces has a downside: [[Development/Tutorials/Debugging/Debugging_symbols|libraries and executables occupy much more disk space than their optimized counter parts]]. That's the reason why many distros choose to install stripped files, '''which results in useless backtraces''':

(no debugging symbols found)
Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread -1233848624 (LWP 12212)]
[New Thread -1255081072 (LWP 12820)]
[New Thread -1240921200 (LWP 12819)]
[New Thread -1266680944 (LWP 12818)]
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
0xffffe410 in __kernel_vsyscall ()
#0 0xffffe410 in __kernel_vsyscall ()
#1 0xb6a1210b in ?? () from /lib/tls/i686/cmov/libpthread.so.0
#2 0xb6a85afe in ?? () from /usr/lib/libX11.so.6
#3 0x00000003 in ?? ()
#4 0x082149c0 in ?? ()
#5 0x00003ffc in ?? ()
#6 0x00000000 in ?? ()

But no worries, with some modifications you can create full blown backtraces for KDE applications.

===Preparing your KDE packages===

If your distribution has debugging-enabled packages, install them.

It is easy to see which debug packages you are missing from looking at the backtrace. For example, take the following line from a backtrace:

#6 0xb7975bdc in ?? () from /usr/lib/libkmailprivate.so.4

The <tt>??</tt> indicates that the library <tt>libkmailprivate.so.4</tt> does not have debug information, which might be available in separate debug packages. In this case, it is pretty easy to guess that you need to install debug packages for KMail to get a better backtrace.

Sometimes, you need to install more than one debug package to get a good backtrace. This depends on how the distribution splits up the packages. For example, for some distributions it is enough to install the debug package for <tt>kdepim</tt> to get enough debugging information for a crash in KMail, for other distributions there is an additional debug package just for KMail.

Here's a list of how to obtain debug packages for some distributions:

*'''Debian''' - Debian offers <tt>-dbg</tt> packages to easy create useful backtraces. Just install the corresponding <tt>-dbg</tt> package. e.g. <tt>kdepim-dbg</tt> for KMail crashes. The dependencies of -dbg makes sure to pull in the other right packages (kdelibs-dbg, gdb, and so on).
*'''FreeBSD ports''' - Please refer to the [http://freebsd.kde.org/faq.php#AKDEapplicationcrashedandIwanttofileabugreportathttpbugskdeorgbutthebacktraceintheKDECrashManagerisuselessWhatcanIdo KDE on FreeBSD FAQ].
*'''Gentoo''' - Gentoo has its [http://www.gentoo.org/proj/en/qa/backtraces.xml own document] describing how to proceed.
*'''Mandriva''' - Mandriva 2007.0 and up has additional debugging packages for all of KDE (in fact, for all of its packages). Just install the corresponding <tt>-debug</tt> package, like <tt>kdebase-debug</tt> and <tt>kdemultimedia-debug</tt>. You probably want to install <tt>kdelibs-debug</tt> anyways.
** Note: the <tt>-debug</tt> packages are in separate repositories. For instance, for all packages in <tt>main</tt>, you'll find the debugging package in repository <tt>debug_main</tt>.
*'''Kubuntu/Ubuntu''' - The Ubuntu family makes things quite easy. Every official KDE module has an additional package in the repository, suffixed with <tt>-dbg</tt>. Always install <tt>kdelibs5-dbg</tt>, because all KDE applications use kdelibs (kdelibs-dbg for KDE 3 applications). Then you should install a -dbg package for the application which crashed. For example if KOrganizer crashed you should install <tt>kdepim-dbg</tt> as well. If the program is not from an official KDE module and has no -dbg package, you can install the -dbgsym package from the repository listed on this [https://wiki.kubuntu.org/DebuggingProgramCrash Debugging Program Crashes] page.
**During the Ubuntu development cycle the Apport crash handler is turned on which will report crashes to launchpad.net and do the backtrace for you, if you would rather use the KDE crash handler turn Apport off in /etc/defaults/apport
**Starting with Lucid Lynx (10.04) Kubuntu will be forwarding all non kubuntu specific bugs upstream and had disabled Apport so that DrKonqui will be th edefault crash handler.
*'''openSUSE''' - You should only install the <tt>-debuginfo</tt> packages, for example: <tt>kdepimlibs4-debuginfo</tt>. You can find these packages in [http://en.opensuse.org/KDE/Repositories KDE repositories]. There is also a dedicated [http://en.opensuse.org/Bugs:An_application_crashed openSUSE debugging page].
*'''Fedora''' - In Fedora you just need to do:
*# <tt>yum provides "/usr/lib/libkmailprivate.so.4"</tt> to find out which package provides that file;
*# <tt>debuginfo-install kdepim</tt> as root to install debug packages for that package (dependencies included).
*:A complete and detailed guide for Fedora is available in [http://fedoraproject.org/wiki/StackTraces this document] describing how to proceed. Fedora uses a separate debuginfo repository that has to be enabled. Also consider <tt>auto-update-debug-info</tt> yum plugin to keep debuginfo packages up to date.

If your distribution doesn't have debugging-enabled packages for KDE, you'll have to compile KDE from sources:

* If you're using KDE 3, then at the configure stage, you should supply the parameter <tt>--enable-debug=full</tt> in order to build debug symbols in the resulting files.
* If you're using KDE 4, then at the cmake stage, you should supply the parameter <tt>-DCMAKE_BUILD_TYPE=debugfull</tt>. If you want to specify your own CXXFLAGS, then use <tt>-DCMAKE_BUILD_TYPE=None CMAKE_CXX_FLAGS="-O0 -g"</tt>. You can change the CMAKE_CXX_FLAGS as appropriate for your needs.

Then it's just <tt>make</tt> and <tt>make install</tt> as you're used to.

===Crash!===

Now it's time to crash your application. The KDE Crash Dialog should appear right after the crash, which shows the Backtrace tab.

[[Image:Kde-crash-handler.png|center|300px|KDE Crash Dialog]]

Click that tab and wait for a minute. This process may take quite some memory, so things may go sluggish all of a sudden. But the result should look much better. For example:

Using host libthread_db library "/lib/libthread_db.so.1".
[Thread debugging using libthread_db enabled]
[New Thread -1232783168 (LWP 7604)]
[KCrash handler]
#6 0x0806be76 in TreeMapItem::parent (this=0x0)
at /home/bram/KDE/kde3/kdeaddons/konq-plugins/fsview/treemap.h:285
#7 0x08065fea in TreeMapItemList::compareItems (this=0xbfec04a8, item1=0x0,
item2=0x0)
at /home/bram/KDE/kde3/kdeaddons/konq-plugins/fsview/treemap.cpp:720
#8 0xb7281619 in QGList::operator== () from /usr/qt/3/lib/libqt-mt.so.3
#9 0x0806d498 in QPtrList<TreeMapItem>::operator== (this=0xbfec04a8,
list=@0xbfec0468) at /usr/qt/3/include/qptrlist.h:74
#10 0x08062e18 in TreeMapWidget::mousePressEvent (this=0xbfec03ac,
e=0xbfebff1c)
at /home/bram/KDE/kde3/kdeaddons/konq-plugins/fsview/treemap.cpp:1840
#11 0xb7004a63 in QWidget::event () from /usr/qt/3/lib/libqt-mt.so.3
#12 0xb6f6bca7 in QApplication::internalNotify ()
from /usr/qt/3/lib/libqt-mt.so.3
#13 0xb6f6ca88 in QApplication::notify () from /usr/qt/3/lib/libqt-mt.so.3
#14 0xb7725a84 in KApplication::notify (this=0xbfec055c, receiver=0xbfec03ac,
event=0xbfebff1c)
at /home/bram/KDE/kde3/kdelibs/kdecore/kapplication.cpp:550
#15 0xb6f0bfd2 in QETWidget::translateMouseEvent ()
from /usr/qt/3/lib/libqt-mt.so.3
#16 0xb6f0b8b0 in QApplication::x11ProcessEvent ()
from /usr/qt/3/lib/libqt-mt.so.3
#17 0xb6f1b761 in QEventLoop::processEvents () from /usr/qt/3/lib/libqt-mt.so.3
#18 0xb6f82831 in QEventLoop::enterLoop () from /usr/qt/3/lib/libqt-mt.so.3
#19 0xb6f826b6 in QEventLoop::exec () from /usr/qt/3/lib/libqt-mt.so.3
#20 0xb6f6b72f in QApplication::exec () from /usr/qt/3/lib/libqt-mt.so.3
#21 0x0805181e in main (argc=134673960, argv=0xffffffff)
at /home/bram/KDE/kde3/kdeaddons/konq-plugins/fsview/main.cpp:55

This looks better, right? It shows memory addresses, the source files and line numbers and the parameters passed to functions. Which make it more helpful to the developer where to look for the problem.

{{note|You '''need''' GDB installed to get the backtrace of a crash. Please read the next section to know what GDB is, and how to install it.}}

===Retrieving a backtrace with GDB===

In some cases, it is not possible to create a backtrace with the KDE Crash Dialog. This may be caused by an application which entered an infinite loop, or the crash dialog did not appear at all for some reason. You can try to grab a backtrace with <tt>gdb</tt>, the [http://sourceware.org/gdb/ GNU Debugger]. GDB is widely available through distribution packages.

Invoking GDB differs from the situation. You can run an application from inside gdb, or attach gdb to an already running process. The latter may be useful when an application already has entered an infinite loop. But we will first start with running an application inside gdb. From the shell, run:

$ gdb someKDEapp

The GDB prompt will appear. Note that this does not start the application itself, you should run it by invoking the <tt>run</tt> command:

(gdb) run

This will run the application like you are used to, and you can work with it like normal (it only consumes far more memory and may feel sluggish). Now it's time to reproduce your crash. When you succeed, the application just closes and you should return to your GDB prompt. Now it's time to run the 'backtrace' command:

{{note|Some KDE applications (such as JuK and KTorrent) have special code to ensure that there is only one running instance of the application at a time. For these applications you should type in "run --nofork" at the (gdb) prompt instead of "run" because otherwise gdb will try to debug the wrong process. If you are unsure as to whether to use --nofork just try it. If the application says it's an unknown option you can remove --nofork.}}

(gdb) thread apply all backtrace

This should give a good backtrace which can be posted at the KDE Bugzilla.

In case you want to attach to an existing process, run the following command in the shell:

$ gdb someKDEapp pid

where ''pid'' is the process ID of the process you want to attach to. Once attached, and the process is in an infinite loop, after using the 'backtrace' command again a useful backtrace will appear. You can use 'continue' command to let the application run again and press Ctrl+C in gdb to be able to again enter commands.

===Retrieving a backtrace with Valgrind===

When it comes to crashes, [http://www.valgrind.org Valgrind] is also a useful tool to create a backtrace. It's not a substitution for GDB, but rather a supplement.

When you run an application in valgrind, every piece of memory read or written by the application is being checked. Valgrind will report erroneous memory operations in the standard output or in a log file. Since most crashes are due to an invalid memory read, valgrind can be useful to track down where the problem occurs.

{{note|Valgrind consists of several tools in order to check or profile an application. For this article, we only use memcheck, the default tool when valgrind is being invoked.}}

Like GDB, Valgrind makes running an application much slower, while consuming a lot more resources.

Start the application within valgrind:

$ valgrind --log-file=someKDEapp someKDEapp

Now reproduce the crash. As soon as this happens, the application and valgrind will terminate. What's left is a file named <tt>someKDEapp.pid</tt> where ''pid'' is replaced by the process ID of the valgrind process. The file may list more errors than the one causing the crash. Here's the bit causing the crash which corresponds to the GDB backtrace above:

==23292== Invalid read of size 4
==23292== at 0x806BD9E: TreeMapItem::parent() const (treemap.h:285)
==23292== by 0x8065FB9: TreeMapItemList::compareItems(void*, void*) (treemap.cpp:720)
==23292== by 0x50AC618: QGList::operator==(QGList const&) const (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== by 0x806D3BF: QPtrList<TreeMapItem>::operator==(QPtrList<TreeMapItem> const&) const (qptrlist.h:74)
==23292== by 0x8062DE7: TreeMapWidget::mousePressEvent(QMouseEvent*) (treemap.cpp:1840)
==23292== by 0x4E2FA62: QWidget::event(QEvent*) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== by 0x4D96CA6: QApplication::internalNotify(QObject*, QEvent*) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== by 0x4D97A87: QApplication::notify(QObject*, QEvent*) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== by 0x4809AC3: KApplication::notify(QObject*, QEvent*) (kapplication.cpp:550)
==23292== by 0x4D36FD1: QETWidget::translateMouseEvent(_XEvent const*) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== by 0x4D368AF: QApplication::x11ProcessEvent(_XEvent*) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== by 0x4D46760: QEventLoop::processEvents(unsigned) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== Address 0x2C is not stack'd, malloc'd or (recently) free'd

But to be sure, just attach the whole log file to the crash report.

Development/Tutorials/Debugging/How to create useful crash reports (it)

2010-05-01T16:27:35Z

Panda84: Prima parte di "Creare i pacchetti KDE"

{{Template:I18n/Language Navigation Bar|Development/Tutorials/Debugging/How to create useful crash reports}}

== Introduzione ==

Questo documento descrive come riprodurre un backtrace (ovvero una "traccia dell'esecuzione") di applicazioni KDE che vanno in crash. Inizialmente vengono fornite alcune informazioni generali; nel seguito vengono descritte le procedure per ottenere i pacchetti KDE per varie distribuzioni utili a ottenere i backtrace. Queste parti dovrebbero essere sufficienti per la maggior parte della gente. Ci sono alcune sezioni addizionali su come creare backtrace con il GNU Debugger e con Valgrind, che possono essere utili in alcuni casi.

== Come creare segnalazioni di crash utili ==

Una buona segnalazione di bug nel [http://bugs.kde.org Bugzilla] consiste di due parti: una '''descrizione''' di come riprodurre il crash ed un '''backtrace''' del crash stesso. Se manca uno di questi elementi risulta molto più difficile, se non impossibile, per gli sviluppatori affrontare il problema.

Una descrizione deve consistere di qualcosa più di un solo "si è piantato". È necessario cercare di descrivere qualsiasi cosa venga fatta prima del crash. È stato cliccato su un pulsante, aperto un particolare sito o file che ha causato il problema? Quel piccolo dettaglio che potrebbe sembrare inutile all'utente potrebbe risultare utile allo sviluppatore, quindi è sempre il caso di annotarlo nella segnalazione.

Un articolo approfondito su come scrivere delle buone descrizioni di bug e segnalazioni è disponibile a [http://www.chiark.greenend.org.uk/~sgtatham/bugs.html questo indirizzo], è caldamente consigliato leggerlo prima di effettuare delle segnalazioni.

Il backtrace di un crash non va allegato alla segnalazione; va semplicemente incollato in coda al testo della segnalazione stessa. In questo modo è molto più semplice per gli sviluppatori individuare segnalazioni duplicate dello stesso bug, in quanto la ricerca non avviene anche sul testo degli allegati.

Se si incolla un backtrace in una segnalazione assicurarsi di rimuovere tutte le righe, eccetto un paio, del tipo:

(no debugging symbols found)

dal backtrace, in quanto lo rendono più difficile da leggere.

Sebbene incollare backtrace direttamente sia preferibile rispetto ad aggiungere un allegato, non vanno incollate altre cose come log (valgrind, strace o output del terminale) o esempi di dati (email, file HTML e così via); per queste cose vanno usati gli allegati.

=== Backtrace ===

I backtrace sono essenziali. Possono sembrare senza significato per i non addetti, ma in realtà possono contenere una gran quantità di informazioni utili. Un backtrace descrive quali funzioni sono state chiamate prima del crash, in modo che gli sviluppatori possano tracciare in quale metodo è partito il problema. Ottenere buoni backtrace ha uno svantaggio: [[Development/Tutorials/Debugging/Debugging_symbols|le librerie e gli eseguibili occupano molto più spazio rispetto alla versione ottimizzata]]. È per questo motivo che molte distribuzioni scelgono di intallare file senza simboli di debugging, '''che causa la creazione di backtrace inutili":

(no debugging symbols found)
Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread -1233848624 (LWP 12212)]
[New Thread -1255081072 (LWP 12820)]
[New Thread -1240921200 (LWP 12819)]
[New Thread -1266680944 (LWP 12818)]
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
0xffffe410 in __kernel_vsyscall ()
#0 0xffffe410 in __kernel_vsyscall ()
#1 0xb6a1210b in ?? () from /lib/tls/i686/cmov/libpthread.so.0
#2 0xb6a85afe in ?? () from /usr/lib/libX11.so.6
#3 0x00000003 in ?? ()
#4 0x082149c0 in ?? ()
#5 0x00003ffc in ?? ()
#6 0x00000000 in ?? ()

Per fortuna non c'è da preoccuparsi, con alcune modifiche è possibile creare backtrace con tutte le informazioni necessarie per le applicazioni KDE.

=== Preparare i pacchetti KDE ===

Se la tua distribuzione ha pacchetti predisposti per il debugging è necessario installarli.

È facile vedere quali pacchetti di debug manchino guardando al backtrace. Prendiamo in considerazione la seguente linea di una backtrace:

#6 0xb7975bdc in ?? () from /usr/lib/libkmailprivate.so.4

Il simbolo <tt>??</tt> indica che la libreria <tt>libkmailprivate.so.4</tt> è priva di informazioni di debug, che potrebbero essere disponibili in pacchetti di debug separati. In questo caso, è facile capire che è necessario installare i pacchetti di debug per KMail per ottenere un backtrace migliore.

Alcune volte, c'è bisogno di installare più di un pacchetto di debug per ottenere un buon backtrace. Ciò dipende da come le distribuzioni suddividono i pacchetti. Per esempio, per alcune distribuzioni è sufficiente installare il pacchetto per <tt>kdepim</tt> per avere sufficienti informazioni riguardo un crash in KMail, in altre distribuzioni c'è un pacchetto di debug aggiuntivo per KMail.

Qui c'è una lista di come ottenere i pacchetti di debug per alcune distribuzioni:

*'''Debian''' - Debian offre pacchetti <tt>-dbg</tt> per creare facilmente backtrace utili. Basta installare il corrispondente pacchetto <tt>-dbg</tt>. ad esempio <tt>kdepim-dbg</tt> per i crash di KMail. Le dipendenze di -dbg assicurano di ottenere anche gli altri pacchetti necessari (kdelibs-dbg, gdb, e così via).
*'''FreeBSD ports''' - Fare riferimento alla pagina [http://freebsd.kde.org/faq.php#AKDEapplicationcrashedandIwanttofileabugreportathttpbugskdeorgbutthebacktraceintheKDECrashManagerisuselessWhatcanIdo delle FAQ di KDE su FreeBSD].
*'''Gentoo''' - Gentoo ha [http://www.gentoo.org/proj/en/qa/backtraces.xml una guida] che descrive come procedere.
*'''Mandriva''' - A partire da Mandriva 2007.0 in su ci sono pacchetti addizionali per tutto KDE. È sufficiente installare il corrispondente pacchetto <tt>-debug</tt>, come <tt>kdebase-debug</tt> e <tt>kdemultimedia-debug</tt>. Quasi certamente va installato <tt>kdelibs-debug</tt> in ogni caso.
** Nota: i pacchetti <tt>-debug</tt> sono in repository separati. Ad esempio, per tutti i pacchetti in <tt>main</tt>, si possono trovare i pacchetti di debug nel repository <tt>debug_main</tt>.
*'''Kubuntu/Ubuntu''' - The Ubuntu family makes things quite easy. Every official KDE module has an additional package in the repository, suffixed with <tt>-dbg</tt>. Always install <tt>kdelibs5-dbg</tt>, because all KDE applications use kdelibs (kdelibs-dbg for KDE 3 applications). Then you should install a -dbg package for the application which crashed. For example if KOrganizer crashed you should install <tt>kdepim-dbg</tt> as well. If the program is not from an official KDE module and has no -dbg package, you can install the -dbgsym package from the repository listed on this [https://wiki.kubuntu.org/DebuggingProgramCrash Debugging Program Crashes] page.
*:During the Ubuntu development cycle the Apport crash handler is turned on which will report crashes to launchpad.net and do the backtrace for you, if you would rather use the KDE crash handler turn Apport off in /etc/defaults/apport
*:Starting with Lucid Lynx (10.04) Kubuntu will be forwarding all non kubuntu specific bugs upstream and had disabled Apport so that DrKonqui will be th edefault crash handler.
*'''openSUSE''' - You should only install the <tt>-debuginfo</tt> packages, for example: <tt>kdepimlibs4-debuginfo</tt>. You can find these packages in [http://en.opensuse.org/KDE/Repositories KDE repositories]. There is also a dedicated [http://en.opensuse.org/Bugs:An_application_crashed openSUSE debugging page].
*'''Fedora''' - Fedora has its [http://fedoraproject.org/wiki/StackTraces own document] describing how to proceed. (A debuginfo repository has to be enabled.)

If your distribution doesn't have debugging-enabled packages for KDE, you'll have to compile KDE from sources:

* If you're using KDE 3, then at the configure stage, you should supply the parameter <tt>--enable-debug=full</tt> in order to build debug symbols in the resulting files.
* If you're using KDE 4, then at the cmake stage, you should supply the parameter <tt>-DCMAKE_BUILD_TYPE=debugfull</tt>. If you want to specify your own CXXFLAGS, then use <tt>-DCMAKE_BUILD_TYPE=None CMAKE_CXX_FLAGS="-O0 -g"</tt>. You can change the CMAKE_CXX_FLAGS as appropriate for your needs.

Then it's just <tt>make</tt> and <tt>make install</tt> as you're used to.

===Crash!===

Now it's time to crash your application. The KDE Crash Dialog should appear right after the crash, which shows the Backtrace tab.

[[Image:Kde-crash-handler.png|center|300px|KDE Crash Dialog]]

Click that tab and wait for a minute. This process may take quite some memory, so things may go sluggish all of a sudden. But the result should look much better. For example:

Using host libthread_db library "/lib/libthread_db.so.1".
[Thread debugging using libthread_db enabled]
[New Thread -1232783168 (LWP 7604)]
[KCrash handler]
#6 0x0806be76 in TreeMapItem::parent (this=0x0)
at /home/bram/KDE/kde3/kdeaddons/konq-plugins/fsview/treemap.h:285
#7 0x08065fea in TreeMapItemList::compareItems (this=0xbfec04a8, item1=0x0,
item2=0x0)
at /home/bram/KDE/kde3/kdeaddons/konq-plugins/fsview/treemap.cpp:720
#8 0xb7281619 in QGList::operator== () from /usr/qt/3/lib/libqt-mt.so.3
#9 0x0806d498 in QPtrList<TreeMapItem>::operator== (this=0xbfec04a8,
list=@0xbfec0468) at /usr/qt/3/include/qptrlist.h:74
#10 0x08062e18 in TreeMapWidget::mousePressEvent (this=0xbfec03ac,
e=0xbfebff1c)
at /home/bram/KDE/kde3/kdeaddons/konq-plugins/fsview/treemap.cpp:1840
#11 0xb7004a63 in QWidget::event () from /usr/qt/3/lib/libqt-mt.so.3
#12 0xb6f6bca7 in QApplication::internalNotify ()
from /usr/qt/3/lib/libqt-mt.so.3
#13 0xb6f6ca88 in QApplication::notify () from /usr/qt/3/lib/libqt-mt.so.3
#14 0xb7725a84 in KApplication::notify (this=0xbfec055c, receiver=0xbfec03ac,
event=0xbfebff1c)
at /home/bram/KDE/kde3/kdelibs/kdecore/kapplication.cpp:550
#15 0xb6f0bfd2 in QETWidget::translateMouseEvent ()
from /usr/qt/3/lib/libqt-mt.so.3
#16 0xb6f0b8b0 in QApplication::x11ProcessEvent ()
from /usr/qt/3/lib/libqt-mt.so.3
#17 0xb6f1b761 in QEventLoop::processEvents () from /usr/qt/3/lib/libqt-mt.so.3
#18 0xb6f82831 in QEventLoop::enterLoop () from /usr/qt/3/lib/libqt-mt.so.3
#19 0xb6f826b6 in QEventLoop::exec () from /usr/qt/3/lib/libqt-mt.so.3
#20 0xb6f6b72f in QApplication::exec () from /usr/qt/3/lib/libqt-mt.so.3
#21 0x0805181e in main (argc=134673960, argv=0xffffffff)
at /home/bram/KDE/kde3/kdeaddons/konq-plugins/fsview/main.cpp:55

This looks better, right? It shows memory addresses, the source files and line numbers and the parameters passed to functions. Which make it more helpful to the developer where to look for the problem.

{{note|You '''need''' GDB installed to get the backtrace of a crash. Please read the next section to know what GDB is, and how to install it.}}

===Retrieving a backtrace with GDB===

In some cases, it is not possible to create a backtrace with the KDE Crash Dialog. This may be caused by an application which entered an infinite loop, or the crash dialog did not appear at all for some reason. You can try to grab a backtrace with <tt>gdb</tt>, the [http://sourceware.org/gdb/ GNU Debugger]. GDB is widely available through distribution packages.

Invoking GDB differs from the situation. You can run an application from inside gdb, or attach gdb to an already running process. The latter may be useful when an application already has entered an infinite loop. But we will first start with running an application inside gdb. From the shell, run:

$ gdb someKDEapp

The GDB prompt will appear. Note that this does not start the application itself, you should run it by invoking the <tt>run</tt> command:

(gdb) run

This will run the application like you are used to, and you can work with it like normal (it only consumes far more memory and may feel sluggish). Now it's time to reproduce your crash. When you succeed, the application just closes and you should return to your GDB prompt. Now it's time to run the 'backtrace' command:

{{note|Some KDE applications (such as JuK and KTorrent) have special code to ensure that there is only one running instance of the application at a time. For these applications you should type in "run --nofork" at the (gdb) prompt instead of "run" because otherwise gdb will try to debug the wrong process. If you are unsure as to whether to use --nofork just try it. If the application says it's an unknown option you can remove --nofork.}}

(gdb) thread apply all backtrace

This should give a good backtrace which can be posted at the KDE Bugzilla.

In case you want to attach to an existing process, run the following command in the shell:

$ gdb someKDEapp pid

where ''pid'' is the process ID of the process you want to attach to. Once attached, and the process is in an infinite loop, after using the 'backtrace' command again a useful backtrace will appear. You can use 'continue' command to let the application run again and press Ctrl+C in gdb to be able to again enter commands.

===Retrieving a backtrace with Valgrind===

When it comes to crashes, [http://www.valgrind.org Valgrind] is also a useful tool to create a backtrace. It's not a substitution for GDB, but rather a supplement.

When you run an application in valgrind, every piece of memory read or written by the application is being checked. Valgrind will report erroneous memory operations in the standard output or in a log file. Since most crashes are due to an invalid memory read, valgrind can be useful to track down where the problem occurs.

{{note|Valgrind consists of several tools in order to check or profile an application. For this article, we only use memcheck, the default tool when valgrind is being invoked.}}

Like GDB, Valgrind makes running an application much slower, while consuming a lot more resources.

Start the application within valgrind:

$ valgrind --log-file=someKDEapp someKDEapp

Now reproduce the crash. As soon as this happens, the application and valgrind will terminate. What's left is a file named <tt>someKDEapp.pid</tt> where ''pid'' is replaced by the process ID of the valgrind process. The file may list more errors than the one causing the crash. Here's the bit causing the crash which corresponds to the GDB backtrace above:

==23292== Invalid read of size 4
==23292== at 0x806BD9E: TreeMapItem::parent() const (treemap.h:285)
==23292== by 0x8065FB9: TreeMapItemList::compareItems(void*, void*) (treemap.cpp:720)
==23292== by 0x50AC618: QGList::operator==(QGList const&) const (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== by 0x806D3BF: QPtrList<TreeMapItem>::operator==(QPtrList<TreeMapItem> const&) const (qptrlist.h:74)
==23292== by 0x8062DE7: TreeMapWidget::mousePressEvent(QMouseEvent*) (treemap.cpp:1840)
==23292== by 0x4E2FA62: QWidget::event(QEvent*) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== by 0x4D96CA6: QApplication::internalNotify(QObject*, QEvent*) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== by 0x4D97A87: QApplication::notify(QObject*, QEvent*) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== by 0x4809AC3: KApplication::notify(QObject*, QEvent*) (kapplication.cpp:550)
==23292== by 0x4D36FD1: QETWidget::translateMouseEvent(_XEvent const*) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== by 0x4D368AF: QApplication::x11ProcessEvent(_XEvent*) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== by 0x4D46760: QEventLoop::processEvents(unsigned) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== Address 0x2C is not stack'd, malloc'd or (recently) free'd

But to be sure, just attach the whole log file to the crash report.

Development/Tutorials/Debugging/How to create useful crash reports

2010-05-01T16:21:55Z

Panda84: Fix Fedora paragraph.

{{Template:I18n/Language Navigation Bar|Development/Tutorials/Debugging/How to create useful crash reports}}
==Introduction==

This document describes how to reproduce a useful backtrace of crashing KDE applications. First, some general information is given. Then, we will describe for several distributions how to prepare your KDE packages and gaining the backtrace. This should be enough for most people.
There are additional sections on how to create backtraces with the GNU Debugger and with Valgrind, which are in some cases useful.

==How to create useful crash reports==

A good crash report at [http://bugs.kde.org Bugzilla] consists of two parts: a '''description''' of how to reproduce the crash and a '''backtrace''' of the crash. With one of those elements missing, it is much harder (if not impossible) for developers to tackle the problem.

A description should consist of more than only "it crashed". Try to describe everything you did prior to the crash. Did you click on a button, opened a particular website or file which caused problems? That little detail which may look useless to you may be useful for the developer, so just write it down.

A more insightful article on how to write good bug descriptions is available [http://www.chiark.greenend.org.uk/~sgtatham/bugs.html at this link], please read that before reporting bugs.

Don't attach the backtrace to the bug report. Instead, simply paste it. This way it is much easier for developers to search for duplicate reports, because attachments will not be searched.

If you paste a backtrace to a report, make sure you strip all but one or two of the
(no debugging symbols found)
lines from the backtrace as they make it harder to read.

Even though pasting backtraces directly is preferred over adding an attachment, please do not paste other things like logs (valgrind, strace or terminal output) or example data (mails, HTML files and so on). Use attachments for these items.

===Backtraces===

Backtraces are essential. They may look meaningless to you, but they might actually contain a wealth of useful information. A backtrace describes which functions were called prior to the crash, so that developers may track down in which function the mess started. Having good backtraces has a downside: [[Development/Tutorials/Debugging/Debugging_symbols|libraries and executables occupy much more disk space than their optimized counter parts]]. That's the reason why many distros choose to install stripped files, '''which results in useless backtraces''':

(no debugging symbols found)
Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread -1233848624 (LWP 12212)]
[New Thread -1255081072 (LWP 12820)]
[New Thread -1240921200 (LWP 12819)]
[New Thread -1266680944 (LWP 12818)]
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
0xffffe410 in __kernel_vsyscall ()
#0 0xffffe410 in __kernel_vsyscall ()
#1 0xb6a1210b in ?? () from /lib/tls/i686/cmov/libpthread.so.0
#2 0xb6a85afe in ?? () from /usr/lib/libX11.so.6
#3 0x00000003 in ?? ()
#4 0x082149c0 in ?? ()
#5 0x00003ffc in ?? ()
#6 0x00000000 in ?? ()

But no worries, with some modifications you can create full blown backtraces for KDE applications.

===Preparing your KDE packages===

If your distribution has debugging-enabled packages, install them.

It is easy to see which debug packages you are missing from looking at the backtrace. For example, take the following line from a backtrace:

#6 0xb7975bdc in ?? () from /usr/lib/libkmailprivate.so.4

The <tt>??</tt> indicates that the library <tt>libkmailprivate.so.4</tt> does not have debug information, which might be available in separate debug packages. In this case, it is pretty easy to guess that you need to install debug packages for KMail to get a better backtrace.

Sometimes, you need to install more than one debug package to get a good backtrace. This depends on how the distribution splits up the packages. For example, for some distributions it is enough to install the debug package for <tt>kdepim</tt> to get enough debugging information for a crash in KMail, for other distributions there is an additional debug package just for KMail.

Here's a list of how to obtain debug packages for some distributions:

*'''Debian''' - Debian offers <tt>-dbg</tt> packages to easy create useful backtraces. Just install the corresponding <tt>-dbg</tt> package. e.g. <tt>kdepim-dbg</tt> for KMail crashes. The dependencies of -dbg makes sure to pull in the other right packages (kdelibs-dbg, gdb, and so on).
*'''FreeBSD ports''' - Please refer to the [http://freebsd.kde.org/faq.php#AKDEapplicationcrashedandIwanttofileabugreportathttpbugskdeorgbutthebacktraceintheKDECrashManagerisuselessWhatcanIdo KDE on FreeBSD FAQ].
*'''Gentoo''' - Gentoo has its [http://www.gentoo.org/proj/en/qa/backtraces.xml own document] describing how to proceed.
*'''Mandriva''' - Mandriva 2007.0 and up has additional debugging packages for all of KDE (in fact, for all of its packages). Just install the corresponding <tt>-debug</tt> package, like <tt>kdebase-debug</tt> and <tt>kdemultimedia-debug</tt>. You probably want to install <tt>kdelibs-debug</tt> anyways.
** Note: the <tt>-debug</tt> packages are in separate repositories. For instance, for all packages in <tt>main</tt>, you'll find the debugging package in repository <tt>debug_main</tt>.
*'''Kubuntu/Ubuntu''' - The Ubuntu family makes things quite easy. Every official KDE module has an additional package in the repository, suffixed with <tt>-dbg</tt>. Always install <tt>kdelibs5-dbg</tt>, because all KDE applications use kdelibs (kdelibs-dbg for KDE 3 applications). Then you should install a -dbg package for the application which crashed. For example if KOrganizer crashed you should install <tt>kdepim-dbg</tt> as well. If the program is not from an official KDE module and has no -dbg package, you can install the -dbgsym package from the repository listed on this [https://wiki.kubuntu.org/DebuggingProgramCrash Debugging Program Crashes] page.
*:During the Ubuntu development cycle the Apport crash handler is turned on which will report crashes to launchpad.net and do the backtrace for you, if you would rather use the KDE crash handler turn Apport off in /etc/defaults/apport
*:Starting with Lucid Lynx (10.04) Kubuntu will be forwarding all non kubuntu specific bugs upstream and had disabled Apport so that DrKonqui will be th edefault crash handler.
*'''openSUSE''' - You should only install the <tt>-debuginfo</tt> packages, for example: <tt>kdepimlibs4-debuginfo</tt>. You can find these packages in [http://en.opensuse.org/KDE/Repositories KDE repositories]. There is also a dedicated [http://en.opensuse.org/Bugs:An_application_crashed openSUSE debugging page].
*'''Fedora''' - In Fedora you just need to do:
*# <tt>yum provides "/usr/lib/libkmailprivate.so.4"</tt> to find out which package provides that file;
*# <tt>debuginfo-install kdepim</tt> as root to install debug packages for that package (dependencies included).
*:A complete and detailed guide for Fedora is available in [http://fedoraproject.org/wiki/StackTraces this document] describing how to proceed. Fedora uses a separate debuginfo repository that has to be enabled. Also consider <tt>auto-update-debug-info</tt> yum plugin to keep debuginfo packages up to date.

If your distribution doesn't have debugging-enabled packages for KDE, you'll have to compile KDE from sources:

* If you're using KDE 3, then at the configure stage, you should supply the parameter <tt>--enable-debug=full</tt> in order to build debug symbols in the resulting files.
* If you're using KDE 4, then at the cmake stage, you should supply the parameter <tt>-DCMAKE_BUILD_TYPE=debugfull</tt>. If you want to specify your own CXXFLAGS, then use <tt>-DCMAKE_BUILD_TYPE=None CMAKE_CXX_FLAGS="-O0 -g"</tt>. You can change the CMAKE_CXX_FLAGS as appropriate for your needs.

Then it's just <tt>make</tt> and <tt>make install</tt> as you're used to.

===Crash!===

Now it's time to crash your application. The KDE Crash Dialog should appear right after the crash, which shows the Backtrace tab.

[[Image:Kde-crash-handler.png|center|300px|KDE Crash Dialog]]

Click that tab and wait for a minute. This process may take quite some memory, so things may go sluggish all of a sudden. But the result should look much better. For example:

Using host libthread_db library "/lib/libthread_db.so.1".
[Thread debugging using libthread_db enabled]
[New Thread -1232783168 (LWP 7604)]
[KCrash handler]
#6 0x0806be76 in TreeMapItem::parent (this=0x0)
at /home/bram/KDE/kde3/kdeaddons/konq-plugins/fsview/treemap.h:285
#7 0x08065fea in TreeMapItemList::compareItems (this=0xbfec04a8, item1=0x0,
item2=0x0)
at /home/bram/KDE/kde3/kdeaddons/konq-plugins/fsview/treemap.cpp:720
#8 0xb7281619 in QGList::operator== () from /usr/qt/3/lib/libqt-mt.so.3
#9 0x0806d498 in QPtrList<TreeMapItem>::operator== (this=0xbfec04a8,
list=@0xbfec0468) at /usr/qt/3/include/qptrlist.h:74
#10 0x08062e18 in TreeMapWidget::mousePressEvent (this=0xbfec03ac,
e=0xbfebff1c)
at /home/bram/KDE/kde3/kdeaddons/konq-plugins/fsview/treemap.cpp:1840
#11 0xb7004a63 in QWidget::event () from /usr/qt/3/lib/libqt-mt.so.3
#12 0xb6f6bca7 in QApplication::internalNotify ()
from /usr/qt/3/lib/libqt-mt.so.3
#13 0xb6f6ca88 in QApplication::notify () from /usr/qt/3/lib/libqt-mt.so.3
#14 0xb7725a84 in KApplication::notify (this=0xbfec055c, receiver=0xbfec03ac,
event=0xbfebff1c)
at /home/bram/KDE/kde3/kdelibs/kdecore/kapplication.cpp:550
#15 0xb6f0bfd2 in QETWidget::translateMouseEvent ()
from /usr/qt/3/lib/libqt-mt.so.3
#16 0xb6f0b8b0 in QApplication::x11ProcessEvent ()
from /usr/qt/3/lib/libqt-mt.so.3
#17 0xb6f1b761 in QEventLoop::processEvents () from /usr/qt/3/lib/libqt-mt.so.3
#18 0xb6f82831 in QEventLoop::enterLoop () from /usr/qt/3/lib/libqt-mt.so.3
#19 0xb6f826b6 in QEventLoop::exec () from /usr/qt/3/lib/libqt-mt.so.3
#20 0xb6f6b72f in QApplication::exec () from /usr/qt/3/lib/libqt-mt.so.3
#21 0x0805181e in main (argc=134673960, argv=0xffffffff)
at /home/bram/KDE/kde3/kdeaddons/konq-plugins/fsview/main.cpp:55

This looks better, right? It shows memory addresses, the source files and line numbers and the parameters passed to functions. Which make it more helpful to the developer where to look for the problem.

{{note|You '''need''' GDB installed to get the backtrace of a crash. Please read the next section to know what GDB is, and how to install it.}}

===Retrieving a backtrace with GDB===

In some cases, it is not possible to create a backtrace with the KDE Crash Dialog. This may be caused by an application which entered an infinite loop, or the crash dialog did not appear at all for some reason. You can try to grab a backtrace with <tt>gdb</tt>, the [http://sourceware.org/gdb/ GNU Debugger]. GDB is widely available through distribution packages.

Invoking GDB differs from the situation. You can run an application from inside gdb, or attach gdb to an already running process. The latter may be useful when an application already has entered an infinite loop. But we will first start with running an application inside gdb. From the shell, run:

$ gdb someKDEapp

The GDB prompt will appear. Note that this does not start the application itself, you should run it by invoking the <tt>run</tt> command:

(gdb) run

This will run the application like you are used to, and you can work with it like normal (it only consumes far more memory and may feel sluggish). Now it's time to reproduce your crash. When you succeed, the application just closes and you should return to your GDB prompt. Now it's time to run the 'backtrace' command:

{{note|Some KDE applications (such as JuK and KTorrent) have special code to ensure that there is only one running instance of the application at a time. For these applications you should type in "run --nofork" at the (gdb) prompt instead of "run" because otherwise gdb will try to debug the wrong process. If you are unsure as to whether to use --nofork just try it. If the application says it's an unknown option you can remove --nofork.}}

(gdb) thread apply all backtrace

This should give a good backtrace which can be posted at the KDE Bugzilla.

In case you want to attach to an existing process, run the following command in the shell:

$ gdb someKDEapp pid

where ''pid'' is the process ID of the process you want to attach to. Once attached, and the process is in an infinite loop, after using the 'backtrace' command again a useful backtrace will appear. You can use 'continue' command to let the application run again and press Ctrl+C in gdb to be able to again enter commands.

===Retrieving a backtrace with Valgrind===

When it comes to crashes, [http://www.valgrind.org Valgrind] is also a useful tool to create a backtrace. It's not a substitution for GDB, but rather a supplement.

When you run an application in valgrind, every piece of memory read or written by the application is being checked. Valgrind will report erroneous memory operations in the standard output or in a log file. Since most crashes are due to an invalid memory read, valgrind can be useful to track down where the problem occurs.

{{note|Valgrind consists of several tools in order to check or profile an application. For this article, we only use memcheck, the default tool when valgrind is being invoked.}}

Like GDB, Valgrind makes running an application much slower, while consuming a lot more resources.

Start the application within valgrind:

$ valgrind --log-file=someKDEapp someKDEapp

Now reproduce the crash. As soon as this happens, the application and valgrind will terminate. What's left is a file named <tt>someKDEapp.pid</tt> where ''pid'' is replaced by the process ID of the valgrind process. The file may list more errors than the one causing the crash. Here's the bit causing the crash which corresponds to the GDB backtrace above:

==23292== Invalid read of size 4
==23292== at 0x806BD9E: TreeMapItem::parent() const (treemap.h:285)
==23292== by 0x8065FB9: TreeMapItemList::compareItems(void*, void*) (treemap.cpp:720)
==23292== by 0x50AC618: QGList::operator==(QGList const&) const (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== by 0x806D3BF: QPtrList<TreeMapItem>::operator==(QPtrList<TreeMapItem> const&) const (qptrlist.h:74)
==23292== by 0x8062DE7: TreeMapWidget::mousePressEvent(QMouseEvent*) (treemap.cpp:1840)
==23292== by 0x4E2FA62: QWidget::event(QEvent*) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== by 0x4D96CA6: QApplication::internalNotify(QObject*, QEvent*) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== by 0x4D97A87: QApplication::notify(QObject*, QEvent*) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== by 0x4809AC3: KApplication::notify(QObject*, QEvent*) (kapplication.cpp:550)
==23292== by 0x4D36FD1: QETWidget::translateMouseEvent(_XEvent const*) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== by 0x4D368AF: QApplication::x11ProcessEvent(_XEvent*) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== by 0x4D46760: QEventLoop::processEvents(unsigned) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== Address 0x2C is not stack'd, malloc'd or (recently) free'd

But to be sure, just attach the whole log file to the crash report.

Development/Tutorials/Debugging/How to create useful crash reports

2010-05-01T16:06:49Z

Panda84: Minor fixes to Fedora section.

{{Template:I18n/Language Navigation Bar|Development/Tutorials/Debugging/How to create useful crash reports}}
==Introduction==

This document describes how to reproduce a useful backtrace of crashing KDE applications. First, some general information is given. Then, we will describe for several distributions how to prepare your KDE packages and gaining the backtrace. This should be enough for most people.
There are additional sections on how to create backtraces with the GNU Debugger and with Valgrind, which are in some cases useful.

==How to create useful crash reports==

A good crash report at [http://bugs.kde.org Bugzilla] consists of two parts: a '''description''' of how to reproduce the crash and a '''backtrace''' of the crash. With one of those elements missing, it is much harder (if not impossible) for developers to tackle the problem.

A description should consist of more than only "it crashed". Try to describe everything you did prior to the crash. Did you click on a button, opened a particular website or file which caused problems? That little detail which may look useless to you may be useful for the developer, so just write it down.

A more insightful article on how to write good bug descriptions is available [http://www.chiark.greenend.org.uk/~sgtatham/bugs.html at this link], please read that before reporting bugs.

Don't attach the backtrace to the bug report. Instead, simply paste it. This way it is much easier for developers to search for duplicate reports, because attachments will not be searched.

If you paste a backtrace to a report, make sure you strip all but one or two of the
(no debugging symbols found)
lines from the backtrace as they make it harder to read.

Even though pasting backtraces directly is preferred over adding an attachment, please do not paste other things like logs (valgrind, strace or terminal output) or example data (mails, HTML files and so on). Use attachments for these items.

===Backtraces===

Backtraces are essential. They may look meaningless to you, but they might actually contain a wealth of useful information. A backtrace describes which functions were called prior to the crash, so that developers may track down in which function the mess started. Having good backtraces has a downside: [[Development/Tutorials/Debugging/Debugging_symbols|libraries and executables occupy much more disk space than their optimized counter parts]]. That's the reason why many distros choose to install stripped files, '''which results in useless backtraces''':

(no debugging symbols found)
Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread -1233848624 (LWP 12212)]
[New Thread -1255081072 (LWP 12820)]
[New Thread -1240921200 (LWP 12819)]
[New Thread -1266680944 (LWP 12818)]
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
0xffffe410 in __kernel_vsyscall ()
#0 0xffffe410 in __kernel_vsyscall ()
#1 0xb6a1210b in ?? () from /lib/tls/i686/cmov/libpthread.so.0
#2 0xb6a85afe in ?? () from /usr/lib/libX11.so.6
#3 0x00000003 in ?? ()
#4 0x082149c0 in ?? ()
#5 0x00003ffc in ?? ()
#6 0x00000000 in ?? ()

But no worries, with some modifications you can create full blown backtraces for KDE applications.

===Preparing your KDE packages===

If your distribution has debugging-enabled packages, install them.

It is easy to see which debug packages you are missing from looking at the backtrace. For example, take the following line from a backtrace:

#6 0xb7975bdc in ?? () from /usr/lib/libkmailprivate.so.4

The <tt>??</tt> indicates that the library <tt>libkmailprivate.so.4</tt> does not have debug information, which might be available in separate debug packages. In this case, it is pretty easy to guess that you need to install debug packages for KMail to get a better backtrace.

Sometimes, you need to install more than one debug package to get a good backtrace. This depends on how the distribution splits up the packages. For example, for some distributions it is enough to install the debug package for <tt>kdepim</tt> to get enough debugging information for a crash in KMail, for other distributions there is an additional debug package just for KMail.

Here's a list of how to obtain debug packages for some distributions:

*'''Debian''' - Debian offers <tt>-dbg</tt> packages to easy create useful backtraces. Just install the corresponding <tt>-dbg</tt> package. e.g. <tt>kdepim-dbg</tt> for KMail crashes. The dependencies of -dbg makes sure to pull in the other right packages (kdelibs-dbg, gdb, and so on).
*'''FreeBSD ports''' - Please refer to the [http://freebsd.kde.org/faq.php#AKDEapplicationcrashedandIwanttofileabugreportathttpbugskdeorgbutthebacktraceintheKDECrashManagerisuselessWhatcanIdo KDE on FreeBSD FAQ].
*'''Gentoo''' - Gentoo has its [http://www.gentoo.org/proj/en/qa/backtraces.xml own document] describing how to proceed.
*'''Mandriva''' - Mandriva 2007.0 and up has additional debugging packages for all of KDE (in fact, for all of its packages). Just install the corresponding <tt>-debug</tt> package, like <tt>kdebase-debug</tt> and <tt>kdemultimedia-debug</tt>. You probably want to install <tt>kdelibs-debug</tt> anyways.
** Note: the <tt>-debug</tt> packages are in separate repositories. For instance, for all packages in <tt>main</tt>, you'll find the debugging package in repository <tt>debug_main</tt>.
*'''Kubuntu/Ubuntu''' - The Ubuntu family makes things quite easy. Every official KDE module has an additional package in the repository, suffixed with <tt>-dbg</tt>. Always install <tt>kdelibs5-dbg</tt>, because all KDE applications use kdelibs (kdelibs-dbg for KDE 3 applications). Then you should install a -dbg package for the application which crashed. For example if KOrganizer crashed you should install <tt>kdepim-dbg</tt> as well. If the program is not from an official KDE module and has no -dbg package, you can install the -dbgsym package from the repository listed on this [https://wiki.kubuntu.org/DebuggingProgramCrash Debugging Program Crashes] page.
*:During the Ubuntu development cycle the Apport crash handler is turned on which will report crashes to launchpad.net and do the backtrace for you, if you would rather use the KDE crash handler turn Apport off in /etc/defaults/apport
*:Starting with Lucid Lynx (10.04) Kubuntu will be forwarding all non kubuntu specific bugs upstream and had disabled Apport so that DrKonqui will be th edefault crash handler.
*'''openSUSE''' - You should only install the <tt>-debuginfo</tt> packages, for example: <tt>kdepimlibs4-debuginfo</tt>. You can find these packages in [http://en.opensuse.org/KDE/Repositories KDE repositories]. There is also a dedicated [http://en.opensuse.org/Bugs:An_application_crashed openSUSE debugging page].
*'''Fedora''' - In Fedora you just need to do:
# <tt>yum provides "/usr/lib/libkmailprivate.so.4"</tt> to find out which package provides that file;
# <tt>debuginfo-install kdepim</tt> as root to install debug packages for that package (dependencies included).
A complete and detailed guide for Fedora is available in [http://fedoraproject.org/wiki/StackTraces this document] describing how to proceed. Fedora uses a separate debuginfo repository that has to be enabled. Also consider <tt>auto-update-debug-info</tt> yum plugin to keep debuginfo packages up to date.

If your distribution doesn't have debugging-enabled packages for KDE, you'll have to compile KDE from sources:

* If you're using KDE 3, then at the configure stage, you should supply the parameter <tt>--enable-debug=full</tt> in order to build debug symbols in the resulting files.
* If you're using KDE 4, then at the cmake stage, you should supply the parameter <tt>-DCMAKE_BUILD_TYPE=debugfull</tt>. If you want to specify your own CXXFLAGS, then use <tt>-DCMAKE_BUILD_TYPE=None CMAKE_CXX_FLAGS="-O0 -g"</tt>. You can change the CMAKE_CXX_FLAGS as appropriate for your needs.

Then it's just <tt>make</tt> and <tt>make install</tt> as you're used to.

===Crash!===

Now it's time to crash your application. The KDE Crash Dialog should appear right after the crash, which shows the Backtrace tab.

[[Image:Kde-crash-handler.png|center|300px|KDE Crash Dialog]]

Click that tab and wait for a minute. This process may take quite some memory, so things may go sluggish all of a sudden. But the result should look much better. For example:

Using host libthread_db library "/lib/libthread_db.so.1".
[Thread debugging using libthread_db enabled]
[New Thread -1232783168 (LWP 7604)]
[KCrash handler]
#6 0x0806be76 in TreeMapItem::parent (this=0x0)
at /home/bram/KDE/kde3/kdeaddons/konq-plugins/fsview/treemap.h:285
#7 0x08065fea in TreeMapItemList::compareItems (this=0xbfec04a8, item1=0x0,
item2=0x0)
at /home/bram/KDE/kde3/kdeaddons/konq-plugins/fsview/treemap.cpp:720
#8 0xb7281619 in QGList::operator== () from /usr/qt/3/lib/libqt-mt.so.3
#9 0x0806d498 in QPtrList<TreeMapItem>::operator== (this=0xbfec04a8,
list=@0xbfec0468) at /usr/qt/3/include/qptrlist.h:74
#10 0x08062e18 in TreeMapWidget::mousePressEvent (this=0xbfec03ac,
e=0xbfebff1c)
at /home/bram/KDE/kde3/kdeaddons/konq-plugins/fsview/treemap.cpp:1840
#11 0xb7004a63 in QWidget::event () from /usr/qt/3/lib/libqt-mt.so.3
#12 0xb6f6bca7 in QApplication::internalNotify ()
from /usr/qt/3/lib/libqt-mt.so.3
#13 0xb6f6ca88 in QApplication::notify () from /usr/qt/3/lib/libqt-mt.so.3
#14 0xb7725a84 in KApplication::notify (this=0xbfec055c, receiver=0xbfec03ac,
event=0xbfebff1c)
at /home/bram/KDE/kde3/kdelibs/kdecore/kapplication.cpp:550
#15 0xb6f0bfd2 in QETWidget::translateMouseEvent ()
from /usr/qt/3/lib/libqt-mt.so.3
#16 0xb6f0b8b0 in QApplication::x11ProcessEvent ()
from /usr/qt/3/lib/libqt-mt.so.3
#17 0xb6f1b761 in QEventLoop::processEvents () from /usr/qt/3/lib/libqt-mt.so.3
#18 0xb6f82831 in QEventLoop::enterLoop () from /usr/qt/3/lib/libqt-mt.so.3
#19 0xb6f826b6 in QEventLoop::exec () from /usr/qt/3/lib/libqt-mt.so.3
#20 0xb6f6b72f in QApplication::exec () from /usr/qt/3/lib/libqt-mt.so.3
#21 0x0805181e in main (argc=134673960, argv=0xffffffff)
at /home/bram/KDE/kde3/kdeaddons/konq-plugins/fsview/main.cpp:55

This looks better, right? It shows memory addresses, the source files and line numbers and the parameters passed to functions. Which make it more helpful to the developer where to look for the problem.

{{note|You '''need''' GDB installed to get the backtrace of a crash. Please read the next section to know what GDB is, and how to install it.}}

===Retrieving a backtrace with GDB===

In some cases, it is not possible to create a backtrace with the KDE Crash Dialog. This may be caused by an application which entered an infinite loop, or the crash dialog did not appear at all for some reason. You can try to grab a backtrace with <tt>gdb</tt>, the [http://sourceware.org/gdb/ GNU Debugger]. GDB is widely available through distribution packages.

Invoking GDB differs from the situation. You can run an application from inside gdb, or attach gdb to an already running process. The latter may be useful when an application already has entered an infinite loop. But we will first start with running an application inside gdb. From the shell, run:

$ gdb someKDEapp

The GDB prompt will appear. Note that this does not start the application itself, you should run it by invoking the <tt>run</tt> command:

(gdb) run

This will run the application like you are used to, and you can work with it like normal (it only consumes far more memory and may feel sluggish). Now it's time to reproduce your crash. When you succeed, the application just closes and you should return to your GDB prompt. Now it's time to run the 'backtrace' command:

{{note|Some KDE applications (such as JuK and KTorrent) have special code to ensure that there is only one running instance of the application at a time. For these applications you should type in "run --nofork" at the (gdb) prompt instead of "run" because otherwise gdb will try to debug the wrong process. If you are unsure as to whether to use --nofork just try it. If the application says it's an unknown option you can remove --nofork.}}

(gdb) thread apply all backtrace

This should give a good backtrace which can be posted at the KDE Bugzilla.

In case you want to attach to an existing process, run the following command in the shell:

$ gdb someKDEapp pid

where ''pid'' is the process ID of the process you want to attach to. Once attached, and the process is in an infinite loop, after using the 'backtrace' command again a useful backtrace will appear. You can use 'continue' command to let the application run again and press Ctrl+C in gdb to be able to again enter commands.

===Retrieving a backtrace with Valgrind===

When it comes to crashes, [http://www.valgrind.org Valgrind] is also a useful tool to create a backtrace. It's not a substitution for GDB, but rather a supplement.

When you run an application in valgrind, every piece of memory read or written by the application is being checked. Valgrind will report erroneous memory operations in the standard output or in a log file. Since most crashes are due to an invalid memory read, valgrind can be useful to track down where the problem occurs.

{{note|Valgrind consists of several tools in order to check or profile an application. For this article, we only use memcheck, the default tool when valgrind is being invoked.}}

Like GDB, Valgrind makes running an application much slower, while consuming a lot more resources.

Start the application within valgrind:

$ valgrind --log-file=someKDEapp someKDEapp

Now reproduce the crash. As soon as this happens, the application and valgrind will terminate. What's left is a file named <tt>someKDEapp.pid</tt> where ''pid'' is replaced by the process ID of the valgrind process. The file may list more errors than the one causing the crash. Here's the bit causing the crash which corresponds to the GDB backtrace above:

==23292== Invalid read of size 4
==23292== at 0x806BD9E: TreeMapItem::parent() const (treemap.h:285)
==23292== by 0x8065FB9: TreeMapItemList::compareItems(void*, void*) (treemap.cpp:720)
==23292== by 0x50AC618: QGList::operator==(QGList const&) const (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== by 0x806D3BF: QPtrList<TreeMapItem>::operator==(QPtrList<TreeMapItem> const&) const (qptrlist.h:74)
==23292== by 0x8062DE7: TreeMapWidget::mousePressEvent(QMouseEvent*) (treemap.cpp:1840)
==23292== by 0x4E2FA62: QWidget::event(QEvent*) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== by 0x4D96CA6: QApplication::internalNotify(QObject*, QEvent*) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== by 0x4D97A87: QApplication::notify(QObject*, QEvent*) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== by 0x4809AC3: KApplication::notify(QObject*, QEvent*) (kapplication.cpp:550)
==23292== by 0x4D36FD1: QETWidget::translateMouseEvent(_XEvent const*) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== by 0x4D368AF: QApplication::x11ProcessEvent(_XEvent*) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== by 0x4D46760: QEventLoop::processEvents(unsigned) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== Address 0x2C is not stack'd, malloc'd or (recently) free'd

But to be sure, just attach the whole log file to the crash report.

Development/Tutorials/Debugging/How to create useful crash reports

2010-05-01T16:02:47Z

Panda84: Updated Fedora instructions.

{{Template:I18n/Language Navigation Bar|Development/Tutorials/Debugging/How to create useful crash reports}}
==Introduction==

This document describes how to reproduce a useful backtrace of crashing KDE applications. First, some general information is given. Then, we will describe for several distributions how to prepare your KDE packages and gaining the backtrace. This should be enough for most people.
There are additional sections on how to create backtraces with the GNU Debugger and with Valgrind, which are in some cases useful.

==How to create useful crash reports==

A good crash report at [http://bugs.kde.org Bugzilla] consists of two parts: a '''description''' of how to reproduce the crash and a '''backtrace''' of the crash. With one of those elements missing, it is much harder (if not impossible) for developers to tackle the problem.

A description should consist of more than only "it crashed". Try to describe everything you did prior to the crash. Did you click on a button, opened a particular website or file which caused problems? That little detail which may look useless to you may be useful for the developer, so just write it down.

A more insightful article on how to write good bug descriptions is available [http://www.chiark.greenend.org.uk/~sgtatham/bugs.html at this link], please read that before reporting bugs.

Don't attach the backtrace to the bug report. Instead, simply paste it. This way it is much easier for developers to search for duplicate reports, because attachments will not be searched.

If you paste a backtrace to a report, make sure you strip all but one or two of the
(no debugging symbols found)
lines from the backtrace as they make it harder to read.

Even though pasting backtraces directly is preferred over adding an attachment, please do not paste other things like logs (valgrind, strace or terminal output) or example data (mails, HTML files and so on). Use attachments for these items.

===Backtraces===

Backtraces are essential. They may look meaningless to you, but they might actually contain a wealth of useful information. A backtrace describes which functions were called prior to the crash, so that developers may track down in which function the mess started. Having good backtraces has a downside: [[Development/Tutorials/Debugging/Debugging_symbols|libraries and executables occupy much more disk space than their optimized counter parts]]. That's the reason why many distros choose to install stripped files, '''which results in useless backtraces''':

(no debugging symbols found)
Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread -1233848624 (LWP 12212)]
[New Thread -1255081072 (LWP 12820)]
[New Thread -1240921200 (LWP 12819)]
[New Thread -1266680944 (LWP 12818)]
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
0xffffe410 in __kernel_vsyscall ()
#0 0xffffe410 in __kernel_vsyscall ()
#1 0xb6a1210b in ?? () from /lib/tls/i686/cmov/libpthread.so.0
#2 0xb6a85afe in ?? () from /usr/lib/libX11.so.6
#3 0x00000003 in ?? ()
#4 0x082149c0 in ?? ()
#5 0x00003ffc in ?? ()
#6 0x00000000 in ?? ()

But no worries, with some modifications you can create full blown backtraces for KDE applications.

===Preparing your KDE packages===

If your distribution has debugging-enabled packages, install them.

It is easy to see which debug packages you are missing from looking at the backtrace. For example, take the following line from a backtrace:

#6 0xb7975bdc in ?? () from /usr/lib/libkmailprivate.so.4

The <tt>??</tt> indicates that the library <tt>libkmailprivate.so.4</tt> does not have debug information, which might be available in separate debug packages. In this case, it is pretty easy to guess that you need to install debug packages for KMail to get a better backtrace.

Sometimes, you need to install more than one debug package to get a good backtrace. This depends on how the distribution splits up the packages. For example, for some distributions it is enough to install the debug package for <tt>kdepim</tt> to get enough debugging information for a crash in KMail, for other distributions there is an additional debug package just for KMail.

Here's a list of how to obtain debug packages for some distributions:

*'''Debian''' - Debian offers <tt>-dbg</tt> packages to easy create useful backtraces. Just install the corresponding <tt>-dbg</tt> package. e.g. <tt>kdepim-dbg</tt> for KMail crashes. The dependencies of -dbg makes sure to pull in the other right packages (kdelibs-dbg, gdb, and so on).
*'''FreeBSD ports''' - Please refer to the [http://freebsd.kde.org/faq.php#AKDEapplicationcrashedandIwanttofileabugreportathttpbugskdeorgbutthebacktraceintheKDECrashManagerisuselessWhatcanIdo KDE on FreeBSD FAQ].
*'''Gentoo''' - Gentoo has its [http://www.gentoo.org/proj/en/qa/backtraces.xml own document] describing how to proceed.
*'''Mandriva''' - Mandriva 2007.0 and up has additional debugging packages for all of KDE (in fact, for all of its packages). Just install the corresponding <tt>-debug</tt> package, like <tt>kdebase-debug</tt> and <tt>kdemultimedia-debug</tt>. You probably want to install <tt>kdelibs-debug</tt> anyways.
** Note: the <tt>-debug</tt> packages are in separate repositories. For instance, for all packages in <tt>main</tt>, you'll find the debugging package in repository <tt>debug_main</tt>.
*'''Kubuntu/Ubuntu''' - The Ubuntu family makes things quite easy. Every official KDE module has an additional package in the repository, suffixed with <tt>-dbg</tt>. Always install <tt>kdelibs5-dbg</tt>, because all KDE applications use kdelibs (kdelibs-dbg for KDE 3 applications). Then you should install a -dbg package for the application which crashed. For example if KOrganizer crashed you should install <tt>kdepim-dbg</tt> as well. If the program is not from an official KDE module and has no -dbg package, you can install the -dbgsym package from the repository listed on this [https://wiki.kubuntu.org/DebuggingProgramCrash Debugging Program Crashes] page.
*:During the Ubuntu development cycle the Apport crash handler is turned on which will report crashes to launchpad.net and do the backtrace for you, if you would rather use the KDE crash handler turn Apport off in /etc/defaults/apport
*:Starting with Lucid Lynx (10.04) Kubuntu will be forwarding all non kubuntu specific bugs upstream and had disabled Apport so that DrKonqui will be th edefault crash handler.
*'''openSUSE''' - You should only install the <tt>-debuginfo</tt> packages, for example: <tt>kdepimlibs4-debuginfo</tt>. You can find these packages in [http://en.opensuse.org/KDE/Repositories KDE repositories]. There is also a dedicated [http://en.opensuse.org/Bugs:An_application_crashed openSUSE debugging page].
*'''Fedora''' - In Fedora you just need to do:
# <tt>yum provides "/usr/lib/libkmailprivate.so.4"</tt> to find out which package provides that file;
# <tt>debuginfo-install package-name</tt> to install debug packages for that package (dependencies include.
A complete and detailed guide for Fedora is available in [http://fedoraproject.org/wiki/StackTraces this document] describing how to proceed. Fedora uses a separate debuginfo repository that has to be enabled. Also consider <tt>auto-update-debug-info</tt> yum plugin to keep debuginfo packages up to date.

If your distribution doesn't have debugging-enabled packages for KDE, you'll have to compile KDE from sources:

* If you're using KDE 3, then at the configure stage, you should supply the parameter <tt>--enable-debug=full</tt> in order to build debug symbols in the resulting files.
* If you're using KDE 4, then at the cmake stage, you should supply the parameter <tt>-DCMAKE_BUILD_TYPE=debugfull</tt>. If you want to specify your own CXXFLAGS, then use <tt>-DCMAKE_BUILD_TYPE=None CMAKE_CXX_FLAGS="-O0 -g"</tt>. You can change the CMAKE_CXX_FLAGS as appropriate for your needs.

Then it's just <tt>make</tt> and <tt>make install</tt> as you're used to.

===Crash!===

Now it's time to crash your application. The KDE Crash Dialog should appear right after the crash, which shows the Backtrace tab.

[[Image:Kde-crash-handler.png|center|300px|KDE Crash Dialog]]

Click that tab and wait for a minute. This process may take quite some memory, so things may go sluggish all of a sudden. But the result should look much better. For example:

Using host libthread_db library "/lib/libthread_db.so.1".
[Thread debugging using libthread_db enabled]
[New Thread -1232783168 (LWP 7604)]
[KCrash handler]
#6 0x0806be76 in TreeMapItem::parent (this=0x0)
at /home/bram/KDE/kde3/kdeaddons/konq-plugins/fsview/treemap.h:285
#7 0x08065fea in TreeMapItemList::compareItems (this=0xbfec04a8, item1=0x0,
item2=0x0)
at /home/bram/KDE/kde3/kdeaddons/konq-plugins/fsview/treemap.cpp:720
#8 0xb7281619 in QGList::operator== () from /usr/qt/3/lib/libqt-mt.so.3
#9 0x0806d498 in QPtrList<TreeMapItem>::operator== (this=0xbfec04a8,
list=@0xbfec0468) at /usr/qt/3/include/qptrlist.h:74
#10 0x08062e18 in TreeMapWidget::mousePressEvent (this=0xbfec03ac,
e=0xbfebff1c)
at /home/bram/KDE/kde3/kdeaddons/konq-plugins/fsview/treemap.cpp:1840
#11 0xb7004a63 in QWidget::event () from /usr/qt/3/lib/libqt-mt.so.3
#12 0xb6f6bca7 in QApplication::internalNotify ()
from /usr/qt/3/lib/libqt-mt.so.3
#13 0xb6f6ca88 in QApplication::notify () from /usr/qt/3/lib/libqt-mt.so.3
#14 0xb7725a84 in KApplication::notify (this=0xbfec055c, receiver=0xbfec03ac,
event=0xbfebff1c)
at /home/bram/KDE/kde3/kdelibs/kdecore/kapplication.cpp:550
#15 0xb6f0bfd2 in QETWidget::translateMouseEvent ()
from /usr/qt/3/lib/libqt-mt.so.3
#16 0xb6f0b8b0 in QApplication::x11ProcessEvent ()
from /usr/qt/3/lib/libqt-mt.so.3
#17 0xb6f1b761 in QEventLoop::processEvents () from /usr/qt/3/lib/libqt-mt.so.3
#18 0xb6f82831 in QEventLoop::enterLoop () from /usr/qt/3/lib/libqt-mt.so.3
#19 0xb6f826b6 in QEventLoop::exec () from /usr/qt/3/lib/libqt-mt.so.3
#20 0xb6f6b72f in QApplication::exec () from /usr/qt/3/lib/libqt-mt.so.3
#21 0x0805181e in main (argc=134673960, argv=0xffffffff)
at /home/bram/KDE/kde3/kdeaddons/konq-plugins/fsview/main.cpp:55

This looks better, right? It shows memory addresses, the source files and line numbers and the parameters passed to functions. Which make it more helpful to the developer where to look for the problem.

{{note|You '''need''' GDB installed to get the backtrace of a crash. Please read the next section to know what GDB is, and how to install it.}}

===Retrieving a backtrace with GDB===

In some cases, it is not possible to create a backtrace with the KDE Crash Dialog. This may be caused by an application which entered an infinite loop, or the crash dialog did not appear at all for some reason. You can try to grab a backtrace with <tt>gdb</tt>, the [http://sourceware.org/gdb/ GNU Debugger]. GDB is widely available through distribution packages.

Invoking GDB differs from the situation. You can run an application from inside gdb, or attach gdb to an already running process. The latter may be useful when an application already has entered an infinite loop. But we will first start with running an application inside gdb. From the shell, run:

$ gdb someKDEapp

The GDB prompt will appear. Note that this does not start the application itself, you should run it by invoking the <tt>run</tt> command:

(gdb) run

This will run the application like you are used to, and you can work with it like normal (it only consumes far more memory and may feel sluggish). Now it's time to reproduce your crash. When you succeed, the application just closes and you should return to your GDB prompt. Now it's time to run the 'backtrace' command:

{{note|Some KDE applications (such as JuK and KTorrent) have special code to ensure that there is only one running instance of the application at a time. For these applications you should type in "run --nofork" at the (gdb) prompt instead of "run" because otherwise gdb will try to debug the wrong process. If you are unsure as to whether to use --nofork just try it. If the application says it's an unknown option you can remove --nofork.}}

(gdb) thread apply all backtrace

This should give a good backtrace which can be posted at the KDE Bugzilla.

In case you want to attach to an existing process, run the following command in the shell:

$ gdb someKDEapp pid

where ''pid'' is the process ID of the process you want to attach to. Once attached, and the process is in an infinite loop, after using the 'backtrace' command again a useful backtrace will appear. You can use 'continue' command to let the application run again and press Ctrl+C in gdb to be able to again enter commands.

===Retrieving a backtrace with Valgrind===

When it comes to crashes, [http://www.valgrind.org Valgrind] is also a useful tool to create a backtrace. It's not a substitution for GDB, but rather a supplement.

When you run an application in valgrind, every piece of memory read or written by the application is being checked. Valgrind will report erroneous memory operations in the standard output or in a log file. Since most crashes are due to an invalid memory read, valgrind can be useful to track down where the problem occurs.

{{note|Valgrind consists of several tools in order to check or profile an application. For this article, we only use memcheck, the default tool when valgrind is being invoked.}}

Like GDB, Valgrind makes running an application much slower, while consuming a lot more resources.

Start the application within valgrind:

$ valgrind --log-file=someKDEapp someKDEapp

Now reproduce the crash. As soon as this happens, the application and valgrind will terminate. What's left is a file named <tt>someKDEapp.pid</tt> where ''pid'' is replaced by the process ID of the valgrind process. The file may list more errors than the one causing the crash. Here's the bit causing the crash which corresponds to the GDB backtrace above:

==23292== Invalid read of size 4
==23292== at 0x806BD9E: TreeMapItem::parent() const (treemap.h:285)
==23292== by 0x8065FB9: TreeMapItemList::compareItems(void*, void*) (treemap.cpp:720)
==23292== by 0x50AC618: QGList::operator==(QGList const&) const (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== by 0x806D3BF: QPtrList<TreeMapItem>::operator==(QPtrList<TreeMapItem> const&) const (qptrlist.h:74)
==23292== by 0x8062DE7: TreeMapWidget::mousePressEvent(QMouseEvent*) (treemap.cpp:1840)
==23292== by 0x4E2FA62: QWidget::event(QEvent*) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== by 0x4D96CA6: QApplication::internalNotify(QObject*, QEvent*) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== by 0x4D97A87: QApplication::notify(QObject*, QEvent*) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== by 0x4809AC3: KApplication::notify(QObject*, QEvent*) (kapplication.cpp:550)
==23292== by 0x4D36FD1: QETWidget::translateMouseEvent(_XEvent const*) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== by 0x4D368AF: QApplication::x11ProcessEvent(_XEvent*) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== by 0x4D46760: QEventLoop::processEvents(unsigned) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== Address 0x2C is not stack'd, malloc'd or (recently) free'd

But to be sure, just attach the whole log file to the crash report.

Development/Tutorials/Debugging/How to create useful crash reports (it)

2010-05-01T15:32:27Z

Panda84: Sezione backtrace tradotta.

{{Template:I18n/Language Navigation Bar|Development/Tutorials/Debugging/How to create useful crash reports}}

== Introduzione ==

Questo documento descrive come riprodurre un backtrace (ovvero una "traccia dell'esecuzione") di applicazioni KDE che vanno in crash. Inizialmente vengono fornite alcune informazioni generali; nel seguito vengono descritte le procedure per ottenere i pacchetti KDE per varie distribuzioni utili a ottenere i backtrace. Queste parti dovrebbero essere sufficienti per la maggior parte della gente. Ci sono alcune sezioni addizionali su come creare backtrace con il GNU Debugger e con Valgrind, che possono essere utili in alcuni casi.

== Come creare segnalazioni di crash utili ==

Una buona segnalazione di bug nel [http://bugs.kde.org Bugzilla] consiste di due parti: una '''descrizione''' di come riprodurre il crash ed un '''backtrace''' del crash stesso. Se manca uno di questi elementi risulta molto più difficile, se non impossibile, per gli sviluppatori affrontare il problema.

Una descrizione deve consistere di qualcosa più di un solo "si è piantato". È necessario cercare di descrivere qualsiasi cosa venga fatta prima del crash. È stato cliccato su un pulsante, aperto un particolare sito o file che ha causato il problema? Quel piccolo dettaglio che potrebbe sembrare inutile all'utente potrebbe risultare utile allo sviluppatore, quindi è sempre il caso di annotarlo nella segnalazione.

Un articolo approfondito su come scrivere delle buone descrizioni di bug e segnalazioni è disponibile a [http://www.chiark.greenend.org.uk/~sgtatham/bugs.html questo indirizzo], è caldamente consigliato leggerlo prima di effettuare delle segnalazioni.

Il backtrace di un crash non va allegato alla segnalazione; va semplicemente incollato in coda al testo della segnalazione stessa. In questo modo è molto più semplice per gli sviluppatori individuare segnalazioni duplicate dello stesso bug, in quanto la ricerca non avviene anche sul testo degli allegati.

Se si incolla un backtrace in una segnalazione assicurarsi di rimuovere tutte le righe, eccetto un paio, del tipo:

(no debugging symbols found)

dal backtrace, in quanto lo rendono più difficile da leggere.

Sebbene incollare backtrace direttamente sia preferibile rispetto ad aggiungere un allegato, non vanno incollate altre cose come log (valgrind, strace o output del terminale) o esempi di dati (email, file HTML e così via); per queste cose vanno usati gli allegati.

=== Backtrace ===

I backtrace sono essenziali. Possono sembrare senza significato per i non addetti, ma in realtà possono contenere una gran quantità di informazioni utili. Un backtrace descrive quali funzioni sono state chiamate prima del crash, in modo che gli sviluppatori possano tracciare in quale metodo è partito il problema. Ottenere buoni backtrace ha uno svantaggio: [[Development/Tutorials/Debugging/Debugging_symbols|le librerie e gli eseguibili occupano molto più spazio rispetto alla versione ottimizzata]]. È per questo motivo che molte distribuzioni scelgono di intallare file senza simboli di debugging, '''che causa la creazione di backtrace inutili":

(no debugging symbols found)
Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread -1233848624 (LWP 12212)]
[New Thread -1255081072 (LWP 12820)]
[New Thread -1240921200 (LWP 12819)]
[New Thread -1266680944 (LWP 12818)]
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
0xffffe410 in __kernel_vsyscall ()
#0 0xffffe410 in __kernel_vsyscall ()
#1 0xb6a1210b in ?? () from /lib/tls/i686/cmov/libpthread.so.0
#2 0xb6a85afe in ?? () from /usr/lib/libX11.so.6
#3 0x00000003 in ?? ()
#4 0x082149c0 in ?? ()
#5 0x00003ffc in ?? ()
#6 0x00000000 in ?? ()

Per fortuna non c'è da preoccuparsi, con alcune modifiche è possibile creare backtrace con tutte le informazioni necessarie per le applicazioni KDE.

===Preparing your KDE packages===

If your distribution has debugging-enabled packages, install them.

It is easy to see which debug packages you are missing from looking at the backtrace. For example, take the following line from a backtrace:

#6 0xb7975bdc in ?? () from /usr/lib/libkmailprivate.so.4

The <tt>??</tt> indicates that the library <tt>libkmailprivate.so.4</tt> does not have debug information, which might be available in separate debug packages. In this case, it is pretty easy to guess that you need to install debug packages for KMail to get a better backtrace.

Sometimes, you need to install more than one debug package to get a good backtrace. This depends on how the distribution splits up the packages. For example, for some distributions it is enough to install the debug package for <tt>kdepim</tt> to get enough debugging information for a crash in KMail, for other distributions there is an additional debug package just for KMail.

Here's a list of how to obtain debug packages for some distributions:

*'''Debian''' - Debian offers <tt>-dbg</tt> packages to easy create useful backtraces. Just install the corresponding <tt>-dbg</tt> package. e.g. <tt>kdepim-dbg</tt> for KMail crashes. The dependencies of -dbg makes sure to pull in the other right packages (kdelibs-dbg, gdb, and so on).

*'''FreeBSD ports''' - Please refer to the [http://freebsd.kde.org/faq.php#AKDEapplicationcrashedandIwanttofileabugreportathttpbugskdeorgbutthebacktraceintheKDECrashManagerisuselessWhatcanIdo KDE on FreeBSD FAQ].
*'''Gentoo''' - Gentoo has its [http://www.gentoo.org/proj/en/qa/backtraces.xml own document] describing how to proceed.
*'''Mandriva''' - Mandriva 2007.0 and up has additional debugging packages for all of KDE (in fact, for all of its packages). Just install the corresponding <tt>-debug</tt> package, like <tt>kdebase-debug</tt> and <tt>kdemultimedia-debug</tt>. You probably want to install <tt>kdelibs-debug</tt> anyways.
** Note: the <tt>-debug</tt> packages are in separate repositories. For instance, for all packages in <tt>main</tt>, you'll find the debugging package in repository <tt>debug_main</tt>.
*'''Kubuntu/Ubuntu''' - The Ubuntu family makes things quite easy. Every official KDE module has an additional package in the repository, suffixed with <tt>-dbg</tt>. Always install <tt>kdelibs5-dbg</tt>, because all KDE applications use kdelibs (kdelibs-dbg for KDE 3 applications). Then you should install a -dbg package for the application which crashed. For example if KOrganizer crashed you should install <tt>kdepim-dbg</tt> as well. If the program is not from an official KDE module and has no -dbg package, you can install the -dbgsym package from the repository listed on this [https://wiki.kubuntu.org/DebuggingProgramCrash Debugging Program Crashes] page.
*:During the Ubuntu development cycle the Apport crash handler is turned on which will report crashes to launchpad.net and do the backtrace for you, if you would rather use the KDE crash handler turn Apport off in /etc/defaults/apport
*:Starting with Lucid Lynx (10.04) Kubuntu will be forwarding all non kubuntu specific bugs upstream and had disabled Apport so that DrKonqui will be th edefault crash handler.
*'''openSUSE''' - You should only install the <tt>-debuginfo</tt> packages, for example: <tt>kdepimlibs4-debuginfo</tt>. You can find these packages in [http://en.opensuse.org/KDE/Repositories KDE repositories]. There is also a dedicated [http://en.opensuse.org/Bugs:An_application_crashed openSUSE debugging page].
*'''Fedora''' - Fedora has its [http://fedoraproject.org/wiki/StackTraces own document] describing how to proceed. (A debuginfo repository has to be enabled.)

If your distribution doesn't have debugging-enabled packages for KDE, you'll have to compile KDE from sources:

* If you're using KDE 3, then at the configure stage, you should supply the parameter <tt>--enable-debug=full</tt> in order to build debug symbols in the resulting files.
* If you're using KDE 4, then at the cmake stage, you should supply the parameter <tt>-DCMAKE_BUILD_TYPE=debugfull</tt>. If you want to specify your own CXXFLAGS, then use <tt>-DCMAKE_BUILD_TYPE=None CMAKE_CXX_FLAGS="-O0 -g"</tt>. You can change the CMAKE_CXX_FLAGS as appropriate for your needs.

Then it's just <tt>make</tt> and <tt>make install</tt> as you're used to.

===Crash!===

Now it's time to crash your application. The KDE Crash Dialog should appear right after the crash, which shows the Backtrace tab.

[[Image:Kde-crash-handler.png|center|300px|KDE Crash Dialog]]

Click that tab and wait for a minute. This process may take quite some memory, so things may go sluggish all of a sudden. But the result should look much better. For example:

Using host libthread_db library "/lib/libthread_db.so.1".
[Thread debugging using libthread_db enabled]
[New Thread -1232783168 (LWP 7604)]
[KCrash handler]
#6 0x0806be76 in TreeMapItem::parent (this=0x0)
at /home/bram/KDE/kde3/kdeaddons/konq-plugins/fsview/treemap.h:285
#7 0x08065fea in TreeMapItemList::compareItems (this=0xbfec04a8, item1=0x0,
item2=0x0)
at /home/bram/KDE/kde3/kdeaddons/konq-plugins/fsview/treemap.cpp:720
#8 0xb7281619 in QGList::operator== () from /usr/qt/3/lib/libqt-mt.so.3
#9 0x0806d498 in QPtrList<TreeMapItem>::operator== (this=0xbfec04a8,
list=@0xbfec0468) at /usr/qt/3/include/qptrlist.h:74
#10 0x08062e18 in TreeMapWidget::mousePressEvent (this=0xbfec03ac,
e=0xbfebff1c)
at /home/bram/KDE/kde3/kdeaddons/konq-plugins/fsview/treemap.cpp:1840
#11 0xb7004a63 in QWidget::event () from /usr/qt/3/lib/libqt-mt.so.3
#12 0xb6f6bca7 in QApplication::internalNotify ()
from /usr/qt/3/lib/libqt-mt.so.3
#13 0xb6f6ca88 in QApplication::notify () from /usr/qt/3/lib/libqt-mt.so.3
#14 0xb7725a84 in KApplication::notify (this=0xbfec055c, receiver=0xbfec03ac,
event=0xbfebff1c)
at /home/bram/KDE/kde3/kdelibs/kdecore/kapplication.cpp:550
#15 0xb6f0bfd2 in QETWidget::translateMouseEvent ()
from /usr/qt/3/lib/libqt-mt.so.3
#16 0xb6f0b8b0 in QApplication::x11ProcessEvent ()
from /usr/qt/3/lib/libqt-mt.so.3
#17 0xb6f1b761 in QEventLoop::processEvents () from /usr/qt/3/lib/libqt-mt.so.3
#18 0xb6f82831 in QEventLoop::enterLoop () from /usr/qt/3/lib/libqt-mt.so.3
#19 0xb6f826b6 in QEventLoop::exec () from /usr/qt/3/lib/libqt-mt.so.3
#20 0xb6f6b72f in QApplication::exec () from /usr/qt/3/lib/libqt-mt.so.3
#21 0x0805181e in main (argc=134673960, argv=0xffffffff)
at /home/bram/KDE/kde3/kdeaddons/konq-plugins/fsview/main.cpp:55

This looks better, right? It shows memory addresses, the source files and line numbers and the parameters passed to functions. Which make it more helpful to the developer where to look for the problem.

{{note|You '''need''' GDB installed to get the backtrace of a crash. Please read the next section to know what GDB is, and how to install it.}}

===Retrieving a backtrace with GDB===

In some cases, it is not possible to create a backtrace with the KDE Crash Dialog. This may be caused by an application which entered an infinite loop, or the crash dialog did not appear at all for some reason. You can try to grab a backtrace with <tt>gdb</tt>, the [http://sourceware.org/gdb/ GNU Debugger]. GDB is widely available through distribution packages.

Invoking GDB differs from the situation. You can run an application from inside gdb, or attach gdb to an already running process. The latter may be useful when an application already has entered an infinite loop. But we will first start with running an application inside gdb. From the shell, run:

$ gdb someKDEapp

The GDB prompt will appear. Note that this does not start the application itself, you should run it by invoking the <tt>run</tt> command:

(gdb) run

This will run the application like you are used to, and you can work with it like normal (it only consumes far more memory and may feel sluggish). Now it's time to reproduce your crash. When you succeed, the application just closes and you should return to your GDB prompt. Now it's time to run the 'backtrace' command:

{{note|Some KDE applications (such as JuK and KTorrent) have special code to ensure that there is only one running instance of the application at a time. For these applications you should type in "run --nofork" at the (gdb) prompt instead of "run" because otherwise gdb will try to debug the wrong process. If you are unsure as to whether to use --nofork just try it. If the application says it's an unknown option you can remove --nofork.}}

(gdb) thread apply all backtrace

This should give a good backtrace which can be posted at the KDE Bugzilla.

In case you want to attach to an existing process, run the following command in the shell:

$ gdb someKDEapp pid

where ''pid'' is the process ID of the process you want to attach to. Once attached, and the process is in an infinite loop, after using the 'backtrace' command again a useful backtrace will appear. You can use 'continue' command to let the application run again and press Ctrl+C in gdb to be able to again enter commands.

===Retrieving a backtrace with Valgrind===

When it comes to crashes, [http://www.valgrind.org Valgrind] is also a useful tool to create a backtrace. It's not a substitution for GDB, but rather a supplement.

When you run an application in valgrind, every piece of memory read or written by the application is being checked. Valgrind will report erroneous memory operations in the standard output or in a log file. Since most crashes are due to an invalid memory read, valgrind can be useful to track down where the problem occurs.

{{note|Valgrind consists of several tools in order to check or profile an application. For this article, we only use memcheck, the default tool when valgrind is being invoked.}}

Like GDB, Valgrind makes running an application much slower, while consuming a lot more resources.

Start the application within valgrind:

$ valgrind --log-file=someKDEapp someKDEapp

Now reproduce the crash. As soon as this happens, the application and valgrind will terminate. What's left is a file named <tt>someKDEapp.pid</tt> where ''pid'' is replaced by the process ID of the valgrind process. The file may list more errors than the one causing the crash. Here's the bit causing the crash which corresponds to the GDB backtrace above:

==23292== Invalid read of size 4
==23292== at 0x806BD9E: TreeMapItem::parent() const (treemap.h:285)
==23292== by 0x8065FB9: TreeMapItemList::compareItems(void*, void*) (treemap.cpp:720)
==23292== by 0x50AC618: QGList::operator==(QGList const&) const (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== by 0x806D3BF: QPtrList<TreeMapItem>::operator==(QPtrList<TreeMapItem> const&) const (qptrlist.h:74)
==23292== by 0x8062DE7: TreeMapWidget::mousePressEvent(QMouseEvent*) (treemap.cpp:1840)
==23292== by 0x4E2FA62: QWidget::event(QEvent*) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== by 0x4D96CA6: QApplication::internalNotify(QObject*, QEvent*) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== by 0x4D97A87: QApplication::notify(QObject*, QEvent*) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== by 0x4809AC3: KApplication::notify(QObject*, QEvent*) (kapplication.cpp:550)
==23292== by 0x4D36FD1: QETWidget::translateMouseEvent(_XEvent const*) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== by 0x4D368AF: QApplication::x11ProcessEvent(_XEvent*) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== by 0x4D46760: QEventLoop::processEvents(unsigned) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== Address 0x2C is not stack'd, malloc'd or (recently) free'd

But to be sure, just attach the whole log file to the crash report.

Development/Tutorials/Debugging/How to create useful crash reports (it)

2010-05-01T14:47:50Z

Panda84: Prova di salvataggio

{{Template:I18n/Language Navigation Bar|Development/Tutorials/Debugging/How to create useful crash reports}}

== Introduzione ==

Questo documento descrive come riprodurre un backtrace (ovvero una "traccia dell'esecuzione") di applicazioni KDE che vanno in crash. Inizialmente vengono fornite alcune informazioni generali; nel seguito vengono descritte le procedure per ottenere i pacchetti KDE per varie distribuzioni utili a ottenere i backtrace. Queste parti dovrebbero essere sufficienti per la maggior parte della gente. Ci sono alcune sezioni addizionali su come creare backtrace con il GNU Debugger e con Valgrind, che possono essere utili in alcuni casi.

== Come creare segnalazioni di crash utili ==

Una buona segnalazione di bug nel [http://bugs.kde.org Bugzilla] consiste di due parti: una '''descrizione''' di come riprodurre il crash ed un '''backtrace''' del crash stesso. Se manca uno di questi elementi risulta molto più difficile, se non impossibile, per gli sviluppatori affrontare il problema.

Una descrizione deve consistere di qualcosa più di un solo "si è piantato". È necessario cercare di descrivere qualsiasi cosa venga fatta prima del crash. È stato cliccato su un pulsante, aperto un particolare sito o file che ha causato il problema? Quel piccolo dettaglio che potrebbe sembrare inutile all'utente potrebbe risultare utile allo sviluppatore, quindi è sempre il caso di annotarlo nella segnalazione.

Un articolo approfondito su come scrivere delle buone descrizioni di bug e segnalazioni è disponibile a [http://www.chiark.greenend.org.uk/~sgtatham/bugs.html questo indirizzo], è caldamente consigliato leggerlo prima di effettuare delle segnalazioni.

Il backtrace di un crash non va allegato alla segnalazione; va semplicemente incollato in coda al testo della segnalazione stessa. In questo modo è molto più semplice per gli sviluppatori individuare segnalazioni duplicate dello stesso bug, in quanto la ricerca non avviene anche sul testo degli allegati.

Se si incolla un backtrace in una segnalazione assicurarsi di rimuovere tutte le righe, eccetto un paio, del tipo:

(no debugging symbols found)

dal backtrace, in quanto lo rendono più difficile da leggere.

Sebbene incollare backtrace direttamente sia preferibile rispetto ad aggiungere un allegato, non vanno incollate altre cose come log (valgrind, strace o output del terminale) o esempi di dati (email, file HTML e così via); per queste cose vanno usati gli allegati.

=== Backtrace ===

I backtrace sono essenziali. They may look meaningless to you, but they might actually contain a wealth of useful information. A backtrace describes which functions were called prior to the crash, so that developers may track down in which function the mess started. Having good backtraces has a downside: libraries and executables occupy much more disk space than their optimized counter parts. That's the reason why many distros choose to install stripped files, '''which results in useless backtraces''':

(no debugging symbols found)
Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread -1233848624 (LWP 12212)]
[New Thread -1255081072 (LWP 12820)]
[New Thread -1240921200 (LWP 12819)]
[New Thread -1266680944 (LWP 12818)]
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
0xffffe410 in __kernel_vsyscall ()
#0 0xffffe410 in __kernel_vsyscall ()
#1 0xb6a1210b in ?? () from /lib/tls/i686/cmov/libpthread.so.0
#2 0xb6a85afe in ?? () from /usr/lib/libX11.so.6
#3 0x00000003 in ?? ()
#4 0x082149c0 in ?? ()
#5 0x00003ffc in ?? ()
#6 0x00000000 in ?? ()

But no worries, with some modifications you can create full blown backtraces for KDE applications.

=== Preparing your KDE packages ===

If your distribution has debugging-enabled packages, install them.

It is easy to see which debug packages you are missing from looking at the backtrace. For example, take the following line from a backtrace:

#6 0xb7975bdc in ?? () from /usr/lib/libkmailprivate.so.4

The <tt>??</tt> indicates that the library <tt>libkmailprivate.so.4</tt> does not have debug information, which might be available in separate debug packages. In this case, it is pretty easy to guess that you need to install debug packages for KMail to get a better backtrace.

Sometimes, you need to install more than one debug package to get a good backtrace. This depends on how the distribution splits up the packages. For example, for some distributions it is enough to install the debug package for <tt>kdepim</tt> to get enough debugging information for a crash in KMail, for other distributions there is an additional debug package just for KMail.

Here's a list of how to obtain debug packages for some distributions:

*'''Debian''' - Debian offers <tt>-dbg</tt> packages to easy create useful backtraces. Just install the corresponding <tt>-dbg</tt> package. e.g. <tt>kdepim-dbg</tt> for KMail crashes. The dependencies of -dbg makes sure to pull in the other right packages (kdelibs-dbg, gdb, and so on). 
*'''FreeBSD ports''' - Please refer to the [http://freebsd.kde.org/faq.php#AKDEapplicationcrashedandIwanttofileabugreportathttpbugskdeorgbutthebacktraceintheKDECrashManagerisuselessWhatcanIdo KDE on FreeBSD FAQ].
*'''Gentoo''' - Gentoo has its [http://www.gentoo.org/proj/en/qa/backtraces.xml own document] describing how to proceed.
*'''Mandriva''' - Mandriva 2007.0 and up has additional debugging packages for all of KDE (in fact, for all of its packages). Just install the corresponding <tt>-debug</tt> package, like <tt>kdebase-debug</tt> and <tt>kdemultimedia-debug</tt>. You probably want to install <tt>kdelibs-debug</tt> anyways.
**Note: the <tt>-debug</tt> packages are in separate repositories. For instance, for all packages in <tt>main</tt>, you'll find the debugging package in repository <tt>debug_main</tt>.
*'''Kubuntu/Ubuntu''' - The Ubuntu family makes things quite easy. Every official KDE module has an additional package in the repository, suffixed with <tt>-dbg</tt>. Always install <tt>kdelibs5-dbg</tt>, because all KDE applications use kdelibs (kdelibs-dbg for KDE 3 applications). Then you should install a -dbg package for the application which crashed. For example if KOrganizer crashed you should install <tt>kdepim-dbg</tt> as well. If the program is not from an official KDE module and has no -dbg package, you can install the -dbgsym package from the repository listed on this [https://wiki.kubuntu.org/DebuggingProgramCrash Debugging Program Crashes] page.
*'''openSUSE''' - You should only install the <tt>-debuginfo</tt> packages, for example: <tt>kdepimlibs4-debuginfo</tt>. You can find these packages in [http://en.opensuse.org/KDE/Repositories KDE repositories]. There is also a dedicated [http://en.opensuse.org/Bugs:An_application_crashed openSUSE debugging page].
*'''Fedora''' - Fedora has its [http://fedoraproject.org/wiki/StackTraces own document] describing how to proceed. (A debuginfo repository has to be enabled.)

If your distribution doesn't have debugging-enabled packages for KDE, you'll have to compile KDE from sources:

*If you're using KDE 3, then at the configure stage, you should supply the parameter <tt>--enable-debug=full</tt> in order to build debug symbols in the resulting files.
*If you're using KDE 4, then at the cmake stage, you should supply the parameter <tt>-DCMAKE_BUILD_TYPE=debugfull</tt>. If you want to specify your own CXXFLAGS, then use <tt>-DCMAKE_BUILD_TYPE=None CMAKE_CXX_FLAGS="-O0 -g"</tt>. You can change the CMAKE_CXX_FLAGS as appropriate for your needs.

Then it's just <tt>make</tt> and <tt>make install</tt> as you're used to.

=== Crash! ===

Now it's time to crash your application. The KDE Crash Dialog should appear right after the crash, which shows the Backtrace tab.

[[Image:Kde crash dialog1.png|center|300px|KDE Crash Dialog]]

Click that tab and wait for a minute. This process may take quite some memory, so things may go sluggish all of a sudden. But the result should look much better. For example:

Using host libthread_db library "/lib/libthread_db.so.1".
[Thread debugging using libthread_db enabled]
[New Thread -1232783168 (LWP 7604)]
[KCrash handler]
#6 0x0806be76 in TreeMapItem::parent (this=0x0)
at /home/bram/KDE/kde3/kdeaddons/konq-plugins/fsview/treemap.h:285
#7 0x08065fea in TreeMapItemList::compareItems (this=0xbfec04a8, item1=0x0,
item2=0x0)
at /home/bram/KDE/kde3/kdeaddons/konq-plugins/fsview/treemap.cpp:720
#8 0xb7281619 in QGList::operator== () from /usr/qt/3/lib/libqt-mt.so.3
#9 0x0806d498 in QPtrList<TreeMapItem>::operator== (this=0xbfec04a8,
list=@0xbfec0468) at /usr/qt/3/include/qptrlist.h:74
#10 0x08062e18 in TreeMapWidget::mousePressEvent (this=0xbfec03ac,
e=0xbfebff1c)
at /home/bram/KDE/kde3/kdeaddons/konq-plugins/fsview/treemap.cpp:1840
#11 0xb7004a63 in QWidget::event () from /usr/qt/3/lib/libqt-mt.so.3
#12 0xb6f6bca7 in QApplication::internalNotify ()
from /usr/qt/3/lib/libqt-mt.so.3
#13 0xb6f6ca88 in QApplication::notify () from /usr/qt/3/lib/libqt-mt.so.3
#14 0xb7725a84 in KApplication::notify (this=0xbfec055c, receiver=0xbfec03ac,
event=0xbfebff1c)
at /home/bram/KDE/kde3/kdelibs/kdecore/kapplication.cpp:550
#15 0xb6f0bfd2 in QETWidget::translateMouseEvent ()
from /usr/qt/3/lib/libqt-mt.so.3
#16 0xb6f0b8b0 in QApplication::x11ProcessEvent ()
from /usr/qt/3/lib/libqt-mt.so.3
#17 0xb6f1b761 in QEventLoop::processEvents () from /usr/qt/3/lib/libqt-mt.so.3
#18 0xb6f82831 in QEventLoop::enterLoop () from /usr/qt/3/lib/libqt-mt.so.3
#19 0xb6f826b6 in QEventLoop::exec () from /usr/qt/3/lib/libqt-mt.so.3
#20 0xb6f6b72f in QApplication::exec () from /usr/qt/3/lib/libqt-mt.so.3
#21 0x0805181e in main (argc=134673960, argv=0xffffffff)
at /home/bram/KDE/kde3/kdeaddons/konq-plugins/fsview/main.cpp:55

This looks better, right? It shows memory addresses, the source files and line numbers and the parameters passed to functions. Which make it more helpful to the developer where to look for the problem.

{{note|You '''need''' GDB installed to get the backtrace of a crash. Please read the next section to know what GDB is, and how to install it.}}

=== Retrieving a backtrace with GDB ===

In some cases, it is not possible to create a backtrace with the KDE Crash Dialog. This may be caused by an application which entered an infinite loop, or the crash dialog did not appear at all for some reason. You can try to grab a backtrace with <tt>gdb</tt>, the [http://sourceware.org/gdb/ GNU Debugger]. GDB is widely available through distribution packages.

Invoking GDB differs from the situation. You can run an application from inside gdb, or attach gdb to an already running process. The latter may be useful when an application already has entered an infinite loop. But we will first start with running an application inside gdb. From the shell, run:

$ gdb someKDEapp

The GDB prompt will appear. Note that this does not start the application itself, you should run it by invoking the <tt>run</tt> command:

(gdb) run

This will run the application like you are used to, and you can work with it like normal (it only consumes far more memory and may feel sluggish). Now it's time to reproduce your crash. When you succeed, the application just closes and you should return to your GDB prompt. Now it's time to run the 'backtrace' command:

{{note|Some KDE applications (such as JuK and KTorrent) have special code to ensure that there is only one running instance of the application at a time. For these applications you should type in "run --nofork" at the (gdb) prompt instead of "run" because otherwise gdb will try to debug the wrong process. If you are unsure as to whether to use --nofork just try it. If the application says it's an unknown option you can remove --nofork.}}

(gdb) thread apply all backtrace

This should give a good backtrace which can be posted at the KDE Bugzilla.

In case you want to attach to an existing process, run the following command in the shell:

$ gdb someKDEapp pid

where ''pid'' is the process ID of the process you want to attach to. Once attached, and the process is in an infinite loop, after using the 'backtrace' command again a useful backtrace will appear. You can use 'continue' command to let the application run again and press Ctrl+C in gdb to be able to again enter commands.

=== Retrieving a backtrace with Valgrind ===

When it comes to crashes, [http://www.valgrind.org Valgrind] is also a useful tool to create a backtrace. It's not a substitution for GDB, but rather a supplement.

When you run an application in valgrind, every piece of memory read or written by the application is being checked. Valgrind will report erroneous memory operations in the standard output or in a log file. Since most crashes are due to an invalid memory read, valgrind can be useful to track down where the problem occurs.

{{note|Valgrind consists of several tools in order to check or profile an application. For this article, we only use memcheck, the default tool when valgrind is being invoked.}}

Like GDB, Valgrind makes running an application much slower, while consuming a lot more resources.

Start the application within valgrind:

$ valgrind --log-file=someKDEapp someKDEapp

Now reproduce the crash. As soon as this happens, the application and valgrind will terminate. What's left is a file named <tt>someKDEapp.pid</tt> where ''pid'' is replaced by the process ID of the valgrind process. The file may list more errors than the one causing the crash. Here's the bit causing the crash which corresponds to the GDB backtrace above:

==23292== Invalid read of size 4
==23292== at 0x806BD9E: TreeMapItem::parent() const (treemap.h:285)
==23292== by 0x8065FB9: TreeMapItemList::compareItems(void*, void*) (treemap.cpp:720)
==23292== by 0x50AC618: QGList::operator==(QGList const&) const (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== by 0x806D3BF: QPtrList<TreeMapItem>::operator==(QPtrList<TreeMapItem> const&) const (qptrlist.h:74)
==23292== by 0x8062DE7: TreeMapWidget::mousePressEvent(QMouseEvent*) (treemap.cpp:1840)
==23292== by 0x4E2FA62: QWidget::event(QEvent*) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== by 0x4D96CA6: QApplication::internalNotify(QObject*, QEvent*) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== by 0x4D97A87: QApplication::notify(QObject*, QEvent*) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== by 0x4809AC3: KApplication::notify(QObject*, QEvent*) (kapplication.cpp:550)
==23292== by 0x4D36FD1: QETWidget::translateMouseEvent(_XEvent const*) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== by 0x4D368AF: QApplication::x11ProcessEvent(_XEvent*) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== by 0x4D46760: QEventLoop::processEvents(unsigned) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== Address 0x2C is not stack'd, malloc'd or (recently) free'd

But to be sure, just attach the whole log file to the crash report.

User:Panda84/Intervista Nicola Dario

2009-10-04T09:53:42Z

Panda84: Separate le domande.

''Diego'': "Ciao Nicola, ciao Dario! Vi ringrazio per averci concesso questa intervista doppia. Comincio con il fare qualche domanda a Nicola, visto che [http://www.kde-it.org/news.php?extend.285 con Dario ho già avuto modo di scambiare qualche parola]. Ho letto un po' di te [http://www.gigabytes.it/chi-sono/ sul tuo blog], vuoi aggiungere qualcosa o fare qualche aggiornamento?"

''Nicola'': "Sono dovuto andare a rileggere quella pagina per ricordarmi cosa c'era scritto! XD Tutto attuale, niente da aggiungere. :)"

----

''Diego'': "Ho letto che ti piacciono i film di fantascienza, quali sono i tuoi preferiti?"

''Nicola'': "Se parliamo di cinema, The Matrix è in cima alla lista. Se parliamo di telefilm, ho un vero culto per Stargate. 15 stagioni riviste almeno 2 volte :) Mi sto anche appassionando all'ultimo remake di Battlestar Galactica, fatto molto bene secondo me."

----

''Diego'': "Ora c'è la domanda d'obbligo (noi intervistatori amiamo essere noiosi): come mai ti sei appassionato al software e non, chessò, al collezionismo? E come sei arrivato a Linux e soprattutto a KDE? Era già nella prima distribuzione che hai provato o ti ci sei avvicinato successivamente?"

''Nicola'': "A 5 anni, come tutti i bimbi, ho deciso di voler fare l'astronauta, così col tempo mi sono appassionato alla tecnologia. A 8 anni mi hanno regalato il primo computer, e a 12 anni sul libro 'Windows 95 for dummies', ho trovato un capitolo sul Visual Basic 4: il mio primo approccio alla programmazione. Poi è venuta la fase 'Evviva il multiboot!'. Avevo trovato la mia prima distro su un numero di Linux&Co. La filosofia opensource mi è piaciuta subito perché mi metteva a disposizione una serie incredibile di strumenti per saziare la mia sete di conoscenza. La distribuzione in questione era Red Hat 7.3, la prima ad includere l'allora neonato KDE 3.0. Era presentato da un articolo chilometrico in quel numero della rivista, che ha contribuito alla mia iniziale scelta sul desktop, aiutato anche da gnome 1.4 che non era proprio uno splendore :)"

----

''Diego'': "Come vi siete conosciuti voi due? È stato in occasione del [http://socghop.appspot.com/student_project/show/google/gsoc2009/kde/t124022559993 Google Summer of Code 2009] o avete avuto contatti anche in precedenza?"

''Nicola'': "Avevo parlato con Davide Bettio del mio desiderio di partecipare al gsoc. Avevo già un'idea, che tutt'ora ritengo interessante, ma che non convinceva le alte sfere e aveva poche possibilità. Quando Davide ha saputo del progetto riguardo policykit, me ne ha parlato e mi ha messo in contatto con Dario."

''Dario'': "..."

----

''Diego'': "Dario, se non sbaglio [http://lists.kde.org/?l=kde-windows&m=123774212425414&w=2 l'idea di una libreria per l'esecuzione di azioni privilegiate] è venuta a te mentre lavoravi su PolicyKit-KDE, dico bene? Puoi raccontarci com'è nata l'idea e come si è evoluta fino ad essere approvata per il GSoC 2009?"

''Dario'': "..."

----

''Diego'': "So che già avete scritto tanto riguardo all'[http://www.gigabytes.it/2009/07/kde-authorization-library-first-step/ Authorization] [http://www.gigabytes.it/2009/07/kde-authorization-library-second-step/ Framework] [http://www.gigabytes.it/2009/08/kde-authorization-library-final-step/ per KDE], che è già stato [http://drfav.wordpress.com/2009/08/31/tokamak-kauth-into-kdelibs/ importato in kdelibs], sia sui vostri [http://drfav.wordpress.com/2009/09/15/kauth-in-use-privileged-kcmodules/ blog] che nella [http://api.kde.org/4.x-api/kdelibs-apidocs/kdecore/html/namespaceKAuth.html documentazione tecnica] quindi non vi tedio ulteriormente. Vi chiedo solo di spiegare rapidamente, pensando agli utenti alle prime armi del nostro sito, a cosa serve dal loro punto di vista, e perché è importante."

''Nicola'': "Serve ad aiutare gli sviluppatori nella gestione delle proprie credenziali d'utente. Gli utenti finali beneficeranno di una maggiore coerenza nell'interfaccia del sistema, una maggiore integrazione tra applicazioni anche di desktop differenti, e una maggiore sicurezza. Gli admin avranno molta più flessibilità nelle scelte. Tutto questo potrà essere supportato dagli sviluppatori con pochissime righe di codice."

''Dario'': "..."

----

''Diego'': "Dario, mi puoi dire qualche parola anche sull'[http://lists.kde.org/?l=kde-core-devel&m=125081035605469&w=2 integrazione con KIO] (la libreria di copia dei file di KDE) [https://bugs.kde.org/show_bug.cgi?id=179289#c11 di cui ti sei preso carico]? A che punto è? KDE 4.4 è troppo vicino per vedere già qualcosa di funzionante?"

''Dario'': "..."

----

''Diego'': "Nicola, dal tuo blog si capisce che ti piace lavorare con il Mac e che durante il tuo GSoC hai scritto il supporto per la libreria sia per Linux che per Mac (il supporto per Windows è ancora in cerca di un volontario). Come ti sei trovato a sviluppare per KDE sotto Mac? A che punto ritieni che sia il progetto [http://mac.kde.org/ KDE on Mac]?"

''Nicola'': "KDE On Mac è un progetto veramente molto ambizioso e lungi dal venire completato. Il problema principale è che gli utenti Mac si aspettano un look&feel molto differente rispetto alle altre piattaforme, che va oltre la semplice 'natività' fornita da Qt. Per rendere Kate, ad esempio, un editor appetibile ad un utente mac medio, le modifiche da fare all'interfaccia sarebbero tante e tali (e non portabili) che ho il dubbio che mai nessuno le farà... Quando si sviluppa con il mac in mente invece, gli strumenti forniti da Apple (Objective-C e Cocoa) permettono di aderire a queste 'regole' senza muovere un dito. Quindi chi mantiene il progetto dovrebbe porsi una domanda: si vuole fare in modo che gli utenti kde si trovino a casa quando usano un mac, o si vuole attirare utenti mac verso le applicazioni di kde? Nel primo caso, funziona già tutto. Nel secondo caso, purtroppo, si è ancora lontani."

----

''Diego'': "Dario, ho visto che è appena uscita [http://chakra-project.org/news/index.php?/archives/17-Chakra-Alpha3-Test-released.html Chakra alpha 3], la distribuzione con cui collabori: vuoi fare un po' di puro e sano marketing? Nicola, tu la usi? E se no, l'hai mai confessato a Dario? :-D"

''Dario'': "..."

''Nicola'': "Non la uso, e penso che Dario lo sappia. :P Non ho una distro fissa in questo periodo. :)"

----

''Diego'': "Ultima domanda semplice semplice: quanto legno roderebbe un roditore se un roditore potesse rodere il legno?"

''Nicola'': "42"

''Dario'': "..."

----

''Diego'': "Ciao e ancora grazie mille, se volete «lasciare un messaggio» potete farlo!"

''Nicola'': "Buon compleanno a chi fa gli anni :)"

''Dario'': "..."

User:Panda84/Intervista Nicola Dario

2009-10-04T09:51:36Z

Panda84: Aggiunte le risposte di Nicola.

''Diego'': "Ciao Nicola, ciao Dario! Vi ringrazio per averci concesso questa intervista doppia. Comincio con il fare qualche domanda a Nicola, visto che [http://www.kde-it.org/news.php?extend.285 con Dario ho già avuto modo di scambiare qualche parola]. Ho letto un po' di te [http://www.gigabytes.it/chi-sono/ sul tuo blog], vuoi aggiungere qualcosa o fare qualche aggiornamento?"

''Nicola'': "Sono dovuto andare a rileggere quella pagina per ricordarmi cosa c'era scritto! XD Tutto attuale, niente da aggiungere. :)"

''Diego'': "Ho letto che ti piacciono i film di fantascienza, quali sono i tuoi preferiti?"

''Nicola'': "Se parliamo di cinema, The Matrix è in cima alla lista. Se parliamo di telefilm, ho un vero culto per Stargate. 15 stagioni riviste almeno 2 volte :) Mi sto anche appassionando all'ultimo remake di Battlestar Galactica, fatto molto bene secondo me."

''Diego'': "Ora c'è la domanda d'obbligo (noi intervistatori amiamo essere noiosi): come mai ti sei appassionato al software e non, chessò, al collezionismo? E come sei arrivato a Linux e soprattutto a KDE? Era già nella prima distribuzione che hai provato o ti ci sei avvicinato successivamente?"

''Nicola'': "A 5 anni, come tutti i bimbi, ho deciso di voler fare l'astronauta, così col tempo mi sono appassionato alla tecnologia. A 8 anni mi hanno regalato il primo computer, e a 12 anni sul libro 'Windows 95 for dummies', ho trovato un capitolo sul Visual Basic 4: il mio primo approccio alla programmazione. Poi è venuta la fase 'Evviva il multiboot!'. Avevo trovato la mia prima distro su un numero di Linux&Co. La filosofia opensource mi è piaciuta subito perché mi metteva a disposizione una serie incredibile di strumenti per saziare la mia sete di conoscenza. La distribuzione in questione era Red Hat 7.3, la prima ad includere l'allora neonato KDE 3.0. Era presentato da un articolo chilometrico in quel numero della rivista, che ha contribuito alla mia iniziale scelta sul desktop, aiutato anche da gnome 1.4 che non era proprio uno splendore :)"

''Diego'': "Come vi siete conosciuti voi due? È stato in occasione del [http://socghop.appspot.com/student_project/show/google/gsoc2009/kde/t124022559993 Google Summer of Code 2009] o avete avuto contatti anche in precedenza?"

''Nicola'': "Avevo parlato con Davide Bettio del mio desiderio di partecipare al gsoc. Avevo già un'idea, che tutt'ora ritengo interessante, ma che non convinceva le alte sfere e aveva poche possibilità. Quando Davide ha saputo del progetto riguardo policykit, me ne ha parlato e mi ha messo in contatto con Dario."

''Dario'': "..."

''Diego'': "Dario, se non sbaglio [http://lists.kde.org/?l=kde-windows&m=123774212425414&w=2 l'idea di una libreria per l'esecuzione di azioni privilegiate] è venuta a te mentre lavoravi su PolicyKit-KDE, dico bene? Puoi raccontarci com'è nata l'idea e come si è evoluta fino ad essere approvata per il GSoC 2009?"

''Dario'': "..."

''Diego'': "So che già avete scritto tanto riguardo all'[http://www.gigabytes.it/2009/07/kde-authorization-library-first-step/ Authorization] [http://www.gigabytes.it/2009/07/kde-authorization-library-second-step/ Framework] [http://www.gigabytes.it/2009/08/kde-authorization-library-final-step/ per KDE], che è già stato [http://drfav.wordpress.com/2009/08/31/tokamak-kauth-into-kdelibs/ importato in kdelibs], sia sui vostri [http://drfav.wordpress.com/2009/09/15/kauth-in-use-privileged-kcmodules/ blog] che nella [http://api.kde.org/4.x-api/kdelibs-apidocs/kdecore/html/namespaceKAuth.html documentazione tecnica] quindi non vi tedio ulteriormente. Vi chiedo solo di spiegare rapidamente, pensando agli utenti alle prime armi del nostro sito, a cosa serve dal loro punto di vista, e perché è importante."

''Nicola'': "Serve ad aiutare gli sviluppatori nella gestione delle proprie credenziali d'utente. Gli utenti finali beneficeranno di una maggiore coerenza nell'interfaccia del sistema, una maggiore integrazione tra applicazioni anche di desktop differenti, e una maggiore sicurezza. Gli admin avranno molta più flessibilità nelle scelte. Tutto questo potrà essere supportato dagli sviluppatori con pochissime righe di codice."

''Dario'': "..."

''Diego'': "Dario, mi puoi dire qualche parola anche sull'[http://lists.kde.org/?l=kde-core-devel&m=125081035605469&w=2 integrazione con KIO] (la libreria di copia dei file di KDE) [https://bugs.kde.org/show_bug.cgi?id=179289#c11 di cui ti sei preso carico]? A che punto è? KDE 4.4 è troppo vicino per vedere già qualcosa di funzionante?"

''Dario'': "..."

''Diego'': "Nicola, dal tuo blog si capisce che ti piace lavorare con il Mac e che durante il tuo GSoC hai scritto il supporto per la libreria sia per Linux che per Mac (il supporto per Windows è ancora in cerca di un volontario). Come ti sei trovato a sviluppare per KDE sotto Mac? A che punto ritieni che sia il progetto [http://mac.kde.org/ KDE on Mac]?"

''Nicola'': "KDE On Mac è un progetto veramente molto ambizioso e lungi dal venire completato. Il problema principale è che gli utenti Mac si aspettano un look&feel molto differente rispetto alle altre piattaforme, che va oltre la semplice 'natività' fornita da Qt. Per rendere Kate, ad esempio, un editor appetibile ad un utente mac medio, le modifiche da fare all'interfaccia sarebbero tante e tali (e non portabili) che ho il dubbio che mai nessuno le farà... Quando si sviluppa con il mac in mente invece, gli strumenti forniti da Apple (Objective-C e Cocoa) permettono di aderire a queste 'regole' senza muovere un dito. Quindi chi mantiene il progetto dovrebbe porsi una domanda: si vuole fare in modo che gli utenti kde si trovino a casa quando usano un mac, o si vuole attirare utenti mac verso le applicazioni di kde? Nel primo caso, funziona già tutto. Nel secondo caso, purtroppo, si è ancora lontani."

''Diego'': "Dario, ho visto che è appena uscita [http://chakra-project.org/news/index.php?/archives/17-Chakra-Alpha3-Test-released.html Chakra alpha 3], la distribuzione con cui collabori: vuoi fare un po' di puro e sano marketing? Nicola, tu la usi? E se no, l'hai mai confessato a Dario? :-D"

''Dario'': "..."

''Nicola'': "Non la uso, e penso che Dario lo sappia. :P Non ho una distro fissa in questo periodo. :)"

''Diego'': "Ultima domanda semplice semplice: quanto legno roderebbe un roditore se un roditore potesse rodere il legno?"

''Nicola'': "42"

''Dario'': "..."

''Diego'': "Ciao e ancora grazie mille, se volete «lasciare un messaggio» potete farlo!"

''Nicola'': "Buon compleanno a chi fa gli anni :)"

''Dario'': "..."

User:Panda84/Intervista Nicola Dario

2009-10-03T10:51:10Z

Panda84: Altra piccola correzione.

User:Panda84/Intervista Nicola Dario

2009-10-03T10:47:33Z

Panda84: Piccole correzioni.

User:Panda84/Intervista Nicola Dario

2009-10-03T10:41:31Z

Panda84: Aggiunto il link ad api.kde.org

''Diego'': "Ciao Nicola, ciao Dario! Vi ringrazio per averci concesso questa intervista doppia. Comincio con il fare qualche domanda per Nicola, visto che [http://www.kde-it.org/news.php?extend.285 con Dario ho già avuto modo di scambiare qualche parola]. Ho letto un po' di te [http://www.gigabytes.it/chi-sono/ sul tuo blog], vuoi aggiungere qualcosa o fare qualche aggiornamento?"

''Nicola'': "..."

''Diego'': "Ho letto che ti piacciono i film di fantascienza, quali sono i tuoi preferiti?"

''Nicola'': "..."

''Diego'': "Ora c'è la domanda d'obbligo (noi intervistatori amiamo essere noiosi): come mai ti sei appassionato al software e non, chessò, al collezionismo? E come sei arrivato a Linux e soprattutto a KDE? Era già nella prima distribuzione che hai provato o ti ci sei avvicinato successivamente?"

''Nicola'': "..."

''Diego'': "Come vi siete conosciuti? È stato in occasione del [http://socghop.appspot.com/student_project/show/google/gsoc2009/kde/t124022559993 Google Summer of Code 2009] o avete avuto contatti anche in precedenza?"

''Nicola'': "..."

''Dario'': "..."

''Diego'': "Dario, se non sbaglio [http://lists.kde.org/?l=kde-windows&m=123774212425414&w=2 l'idea di una libreria per l'esecuzione di azioni privilegiate] è venuta a te mentre lavoravi su PolicyKit-KDE, dico bene? Puoi raccontarci com'è nata l'idea e come si è evoluta fino ad essere approvata per il GSoC 2009?"

''Dario'': "..."

''Diego'': "So che già avete scritto tanto riguardo all'[http://www.gigabytes.it/2009/07/kde-authorization-library-first-step/ Authorization] [http://www.gigabytes.it/2009/07/kde-authorization-library-second-step/ Framework] [http://www.gigabytes.it/2009/08/kde-authorization-library-final-step/ per KDE], che è già stato [http://drfav.wordpress.com/2009/08/31/tokamak-kauth-into-kdelibs/ importato in kdelibs], sia sui vostri [http://drfav.wordpress.com/2009/09/15/kauth-in-use-privileged-kcmodules/ blog] che nella [http://api.kde.org/4.x-api/kdelibs-apidocs/kdecore/html/namespaceKAuth.html documentazione tecnica] quindi non vi tedio ulteriormente. Vi chiedo solo di spiegare rapidamente, pensando agli utenti alle prime armi del nostro sito, a cosa serve dal loro punto di vista, e perché è importante."

''Nicola'': "..."

''Dario'': "..."

''Diego'': "Dario, mi puoi dire qualche parola anche sull'[http://lists.kde.org/?l=kde-core-devel&m=125081035605469&w=2 integrazione con KIO] (la libreria di copia dei file di KDE) [https://bugs.kde.org/show_bug.cgi?id=179289#c11 di cui ti sei preso carico]? A che punto è? KDE 4.4 è troppo vicino per vedere già qualcosa di funzionante?"

''Dario'': "..."

''Diego'': "Nicola, dal tuo blog si capisce che ti piace lavorare con il Mac e che durante il tuo GSoC ha scritto il supporto per la libreria sia per Linux che per Mac (il supporto per Windows è ancora in cerca di un volontario). Come ti sei trovato a sviluppare per KDE sotto Mac? A che punto ritieni che sia il progetto [http://mac.kde.org/ KDE on Mac]?"

''Nicola'': "..."

''Diego'': "Dario, ho visto che è appena uscita [http://chakra-project.org/news/index.php?/archives/17-Chakra-Alpha3-Test-released.html Chakra alpha 3], la distribuzione con cui collabori: vuoi fare un po' di puro e sano marketing? Nicola, tu la usi, e se no, l'hai mai confessato a Dario? :-D"

''Dario'': "..."

''Nicola'': "..."

''Diego'': "Ultima domanda semplice semplice: quanto legno roderebbe un roditore se un roditore potesse rodere il legno?"

''Nicola'': "..."

''Dario'': "..."

''Diego'': "Ciao e ancora grazie mille, se volete «lasciare un messaggio» potete farlo!"

''Nicola'': "..."

''Dario'': "..."

User:Panda84/Intervista Nicola Dario

2009-10-03T09:54:18Z

Panda84: Finite le domande.

''Diego'': "Ciao Nicola, ciao Dario! Vi ringrazio per averci concesso questa intervista doppia. Comincio con il fare qualche domanda per Nicola, visto che [http://www.kde-it.org/news.php?extend.285 con Dario ho già avuto modo di scambiare qualche parola]. Ho letto un po' di te [http://www.gigabytes.it/chi-sono/ sul tuo blog], vuoi aggiungere qualcosa o fare qualche aggiornamento?"

''Nicola'': "..."

''Diego'': "Ho letto che ti piacciono i film di fantascienza, quali sono i tuoi preferiti?"

''Nicola'': "..."

''Diego'': "Ora c'è la domanda d'obbligo (noi intervistatori amiamo essere noiosi): come mai ti sei appassionato al software e non, chessò, al collezionismo? E come sei arrivato a Linux e soprattutto a KDE? Era già nella prima distribuzione che hai provato o ti ci sei avvicinato successivamente?"

''Nicola'': "..."

''Diego'': "Come vi siete conosciuti? È stato in occasione del [http://socghop.appspot.com/student_project/show/google/gsoc2009/kde/t124022559993 Google Summer of Code 2009] o avete avuto contatti anche in precedenza?"

''Nicola'': "..."

''Dario'': "..."

''Diego'': "Dario, se non sbaglio [http://lists.kde.org/?l=kde-windows&m=123774212425414&w=2 l'idea di una libreria per l'esecuzione di azioni privilegiate] è venuta a te mentre lavoravi su PolicyKit-KDE, dico bene? Puoi raccontarci com'è nata l'idea e come si è evoluta fino ad essere approvata per il GSoC 2009?"

''Dario'': "..."

''Diego'': "So che già avete scritto tanto riguardo all'[http://www.gigabytes.it/2009/07/kde-authorization-library-first-step/ Authorization] [http://www.gigabytes.it/2009/07/kde-authorization-library-second-step/ Framework] [http://www.gigabytes.it/2009/08/kde-authorization-library-final-step/ per KDE], che è già stato [http://drfav.wordpress.com/2009/08/31/tokamak-kauth-into-kdelibs/ importato in kdelibs], sia sui vostri [http://drfav.wordpress.com/2009/09/15/kauth-in-use-privileged-kcmodules/ blog] che nella [ documentazione tecnica] quindi non vi tedio ulteriormente. Vi chiedo solo di spiegare rapidamente, pensando agli utenti alle prime armi del nostro sito, a cosa serve dal loro punto di vista, e perché è importante."

''Nicola'': "..."

''Dario'': "..."

''Diego'': "Dario, mi puoi dire qualche parola anche sull'[http://lists.kde.org/?l=kde-core-devel&m=125081035605469&w=2 integrazione con KIO] (la libreria di copia dei file di KDE) [https://bugs.kde.org/show_bug.cgi?id=179289#c11 di cui ti sei preso carico]? A che punto è? KDE 4.4 è troppo vicino per vedere già qualcosa di funzionante?"

''Dario'': "..."

''Diego'': "Nicola, dal tuo blog si capisce che ti piace lavorare con il Mac e che durante il tuo GSoC ha scritto il supporto per la libreria sia per Linux che per Mac (il supporto per Windows è ancora in cerca di un volontario). Come ti sei trovato a sviluppare per KDE sotto Mac? A che punto ritieni che sia il progetto [http://mac.kde.org/ KDE on Mac]?"

''Nicola'': "..."

''Diego'': "Dario, ho visto che è appena uscita [http://chakra-project.org/news/index.php?/archives/17-Chakra-Alpha3-Test-released.html Chakra alpha 3], la distribuzione con cui collabori: vuoi fare un po' di puro e sano marketing? Nicola, tu la usi, e se no, l'hai mai confessato a Dario? :-D"

''Dario'': "..."

''Nicola'': "..."

''Diego'': "Ultima domanda semplice semplice: quanto legno roderebbe un roditore se un roditore potesse rodere il legno?"

''Nicola'': "..."

''Dario'': "..."

''Diego'': "Ciao e ancora grazie mille, se volete «lasciare un messaggio» potete farlo!"

''Nicola'': "..."

''Dario'': "..."

User:Panda84/Intervista Nicola Dario

2009-10-03T09:50:16Z

Panda84: Quasi finito con le domande.

''Diego'': "Ciao Nicola, ciao Dario! Vi ringrazio per averci concesso questa intervista doppia. Comincio con il fare qualche domanda per Nicola, visto che [http://www.kde-it.org/news.php?extend.285 con Dario ho già avuto modo di scambiare qualche parola]. Ho letto un po' di te [http://www.gigabytes.it/chi-sono/ sul tuo blog], vuoi aggiungere qualcosa o fare qualche aggiornamento?"

''Nicola'': "..."

''Diego'': "Ho letto che ti piacciono i film di fantascienza, quali sono i tuoi preferiti?"

''Nicola'': "..."

''Diego'': "Ora c'è la domanda d'obbligo (noi intervistatori amiamo essere noiosi): come mai ti sei appassionato al software e non, chessò, al collezionismo? E come sei arrivato a Linux e soprattutto a KDE? Era già nella prima distribuzione che hai provato o ti ci sei avvicinato successivamente?"

''Nicola'': "..."

''Diego'': "Come vi siete conosciuti? È stato in occasione del [http://socghop.appspot.com/student_project/show/google/gsoc2009/kde/t124022559993 Google Summer of Code 2009] o avete avuto contatti anche in precedenza?"

''Nicola'': "..."

''Dario'': "..."

''Diego'': "Dario, se non sbaglio [http://lists.kde.org/?l=kde-windows&m=123774212425414&w=2 l'idea di una libreria per l'esecuzione di azioni privilegiate] è venuta a te mentre lavoravi su PolicyKit-KDE, dico bene? Puoi raccontarci com'è nata l'idea e come si è evoluta fino ad essere approvata per il GSoC 2009?"

''Dario'': "..."

''Diego'': "So che già avete scritto tanto riguardo all'[http://www.gigabytes.it/2009/07/kde-authorization-library-first-step/ Authorization] [http://www.gigabytes.it/2009/07/kde-authorization-library-second-step/ Framework] [http://www.gigabytes.it/2009/08/kde-authorization-library-final-step/ per KDE], che è già stato [http://drfav.wordpress.com/2009/08/31/tokamak-kauth-into-kdelibs/ importato in kdelibs], sia sui vostri [http://drfav.wordpress.com/2009/09/15/kauth-in-use-privileged-kcmodules/ blog] che nella [ documentazione tecnica] quindi non vi tedio ulteriormente. Vi chiedo solo di spiegare rapidamente, pensando agli utenti alle prime armi del nostro sito, a cosa serve dal loro punto di vista, e perché è importante."

''Nicola'': "..."

''Dario'': "..."

''Diego'': "Dario, mi puoi dire qualche parola anche sull'[http://lists.kde.org/?l=kde-core-devel&m=125081035605469&w=2 integrazione con KIO] (la libreria di copia dei file di KDE) [https://bugs.kde.org/show_bug.cgi?id=179289#c11 di cui ti sei preso carico]? A che punto è? KDE 4.4 è troppo vicino per vedere già qualcosa di funzionante?"

''Dario'': "..."

''Diego'': "Nicola, dal tuo blog si capisce che ti piace lavorare con il Mac e che durante il tuo GSoC ha scritto il supporto per la libreria sia per Linux che per Mac (il supporto per Windows è ancora in cerca di un volontario). Come ti sei trovato a sviluppare per KDE sotto Mac? A che punto ritieni che sia il progetto [http://mac.kde.org/ KDE on Mac]?"

''Nicola'': "..."

''Diego'': "Dario, ho visto che è appena uscita [http://chakra-project.org/news/index.php?/archives/17-Chakra-Alpha3-Test-released.html Chakra alpha 3], la distribuzione con cui collabori: vuoi fare un po' di puro e sano marketing? Nicola, tu la usi, e se no, l'hai mai confessato a Dario? :-D"

''Dario'': "..."

''Nicola'': "..."

User:Panda84/Intervista Nicola Dario

2009-10-03T09:32:00Z

Panda84: Domande a metà.

User:Panda84/Intervista Nicola Dario

2009-10-03T09:08:28Z

Panda84: Prime domande a Nicola

User:Panda84

2009-10-03T08:51:04Z

Panda84: Aggiunta intervista a Nicola e Dario

== whoami ==

I'm an Italian KDE user willing to become a KDE developer sooner or later. :)

I thought that the first step to become a developer was reading developer's documentation... and then why not translate it after reading?

== DONE ==

Pages translated:
* 18/07/2008 - [[Help:Wiki_Translation_(it)|Help : Wiki translation]] - let's start from the beginning, am I right? :)
* 15/08/2008 - [[Help:Contents_(it)|Help : Contents]]
* 16/08/2008 - [[Help:Contribute_(it)|Help : Contribute]]
* 28/09/2008 - [[Help:Wiki_Structure_(it)|Help : Wiki Structure]]

== WORK IN PROGRESS ==

* 23/03/2009 - [[User:Panda84/Development/Tutorials/Debugging/How_to_create_useful_crash_reports_(it)|Debugging : How to create useful crash report]]
* 03/10/2009 - [[User:Panda84/Intervista_Nicola_Dario | Intervista a Nicola Gigante e Dario Freddi]]

== TODO ==

I'll translate all pages that'll come on my way!

Development/Tutorials/Debugging/How to create useful crash reports (it)

2009-03-23T21:15:23Z

Panda84: Tradotti primi paragrafi.

{{Template:I18n/Language Navigation Bar|Development/Tutorials/Debugging/How to create useful crash reports}}
==Introduzione==

Questo documento descrive come riprodurre un backtrace (ovvero una "traccia dell'esecuzione") di applicazioni KDE che vanno in crash. Inizialmente vengono fornite alcune informazioni generali; nel seguito vengono descritte le procedure per ottenere i pacchetti KDE per varie distribuzioni utili a ottenere i backtrace. Queste parti dovrebbero essere sufficienti per la maggior parte della gente.
Ci sono alcune sezioni addizionali su come creare backtrace con il GNU Debugger e con Valgrind, che possono essere utili in alcuni casi.

==Come creare segnalazioni di crash utili==

Una buona segnalazione di bug nel [http://bugs.kde.org Bugzilla] consiste di due parti: una '''descrizione''' di come riprodurre il crash ed un '''backtrace''' del crash stesso. Se manca uno di questi elementi risulta molto più difficile, se non impossibile, per gli sviluppatori affrontare il problema.

Una descrizione deve consistere di qualcosa più di un solo "si è piantato". È necessario cercare di descrivere qualsiasi cosa venga fatta prima del crash. È stato cliccato su un pulsante, aperto un particolare sito o file che ha causato il problema? Quel piccolo dettaglio che potrebbe sembrare inutile all'utente potrebbe risultare utile allo sviluppatore, quindi è sempre il caso di annotarlo nella segnalazione.

Un articolo approfondito su come scrivere delle buone descrizioni di bug e segnalazioni è disponibile a [http://www.chiark.greenend.org.uk/~sgtatham/bugs.html questo indirizzo], è caldamente consigliato leggerlo prima di effettuare delle segnalazioni.

Il backtrace di un crash non va allegato alla segnalazione; va semplicemente incollato in coda al testo della segnalazione stessa. In questo modo è molto più semplice per gli sviluppatori individuare segnalazioni duplicate dello stesso bug, in quanto la ricerca non avviene anche sul testo degli allegati.

Se si incolla un backtrace in una segnalazione assicurarsi di rimuovere tutte le righe, eccetto un paio, del tipo:
(no debugging symbols found)
dal backtrace, in quanto lo rendono più difficile da leggere.

Sebbene incollare backtrace direttamente sia preferibile rispetto ad aggiungere un allegato, non vanno incollate altre cose come log (valgrind, strace o output del terminale) o esempi di dati (email, file HTML e così via); per queste cose vanno usati gli allegati.

===Backtraces===

Backtraces are essential. They may look meaningless to you, but they might actually contain a wealth of useful information. A backtrace describes which functions were called prior to the crash, so that developers may track down in which function the mess started. Having good backtraces has a downside: libraries and executables occupy much more disk space than their optimized counter parts. That's the reason why many distros choose to install stripped files, '''which results in useless backtraces''':

(no debugging symbols found)
Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread -1233848624 (LWP 12212)]
[New Thread -1255081072 (LWP 12820)]
[New Thread -1240921200 (LWP 12819)]
[New Thread -1266680944 (LWP 12818)]
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
0xffffe410 in __kernel_vsyscall ()
#0 0xffffe410 in __kernel_vsyscall ()
#1 0xb6a1210b in ?? () from /lib/tls/i686/cmov/libpthread.so.0
#2 0xb6a85afe in ?? () from /usr/lib/libX11.so.6
#3 0x00000003 in ?? ()
#4 0x082149c0 in ?? ()
#5 0x00003ffc in ?? ()
#6 0x00000000 in ?? ()

But no worries, with some modifications you can create full blown backtraces for KDE applications.

===Preparing your KDE packages===

If your distribution has debugging-enabled packages, install them.

It is easy to see which debug packages you are missing from looking at the backtrace. For example, take the following line from a backtrace:

#6 0xb7975bdc in ?? () from /usr/lib/libkmailprivate.so.4

The <tt>??</tt> indicates that the library <tt>libkmailprivate.so.4</tt> does not have debug information, which might be available in separate debug packages. In this case, it is pretty easy to guess that you need to install debug packages for KMail to get a better backtrace.

Sometimes, you need to install more than one debug package to get a good backtrace. This depends on how the distribution splits up the packages. For example, for some distributions it is enough to install the debug package for <tt>kdepim</tt> to get enough debugging information for a crash in KMail, for other distributions there is an additional debug package just for KMail.

Here's a list of how to obtain debug packages for some distributions:

*'''Debian''' - Debian offers <tt>-dbg</tt> packages to easy create useful backtraces. Just install the corresponding <tt>-dbg</tt> package. e.g. <tt>kdepim-dbg</tt> for KMail crashes. The dependencies of -dbg makes sure to pull in the other right packages (kdelibs-dbg, gdb, and so on).

*'''FreeBSD ports''' - Please refer to the [http://freebsd.kde.org/faq.php#AKDEapplicationcrashedandIwanttofileabugreportathttpbugskdeorgbutthebacktraceintheKDECrashManagerisuselessWhatcanIdo KDE on FreeBSD FAQ].
*'''Gentoo''' - Gentoo has its [http://www.gentoo.org/proj/en/qa/backtraces.xml own document] describing how to proceed.
*'''Mandriva''' - Mandriva 2007.0 and up has additional debugging packages for all of KDE (in fact, for all of its packages). Just install the corresponding <tt>-debug</tt> package, like <tt>kdebase-debug</tt> and <tt>kdemultimedia-debug</tt>. You probably want to install <tt>kdelibs-debug</tt> anyways.
** Note: the <tt>-debug</tt> packages are in separate repositories. For instance, for all packages in <tt>main</tt>, you'll find the debugging package in repository <tt>debug_main</tt>.
*'''Kubuntu/Ubuntu''' - The Ubuntu family makes things quite easy. Every official KDE module has an additional package in the repository, suffixed with <tt>-dbg</tt>. Always install <tt>kdelibs5-dbg</tt>, because all KDE applications use kdelibs (kdelibs-dbg for KDE 3 applications). Then you should install a -dbg package for the application which crashed. For example if KOrganizer crashed you should install <tt>kdepim-dbg</tt> as well. If the program is not from an official KDE module and has no -dbg package, you can install the -dbgsym package from the repository listed on this [https://wiki.kubuntu.org/DebuggingProgramCrash Debugging Program Crashes] page.
*'''openSUSE''' - You should only install the <tt>-debuginfo</tt> packages, for example: <tt>kdepimlibs4-debuginfo</tt>. You can find these packages in [http://en.opensuse.org/KDE/Repositories KDE repositories]. There is also a dedicated [http://en.opensuse.org/Bugs:An_application_crashed openSUSE debugging page].
*'''Fedora''' - Fedora has its [http://fedoraproject.org/wiki/StackTraces own document] describing how to proceed. (A debuginfo repository has to be enabled.)

If your distribution doesn't have debugging-enabled packages for KDE, you'll have to compile KDE from sources:

* If you're using KDE 3, then at the configure stage, you should supply the parameter <tt>--enable-debug=full</tt> in order to build debug symbols in the resulting files.
* If you're using KDE 4, then at the cmake stage, you should supply the parameter <tt>-DCMAKE_BUILD_TYPE=debugfull</tt>. If you want to specify your own CXXFLAGS, then use <tt>-DCMAKE_BUILD_TYPE=None CMAKE_CXX_FLAGS="-O0 -g"</tt>. You can change the CMAKE_CXX_FLAGS as appropriate for your needs.

Then it's just <tt>make</tt> and <tt>make install</tt> as you're used to.

===Crash!===

Now it's time to crash your application. The KDE Crash Dialog should appear right after the crash, which shows the Backtrace tab.

[[Image:Kde crash dialog1.png|center|300px|KDE Crash Dialog]]

Click that tab and wait for a minute. This process may take quite some memory, so things may go sluggish all of a sudden. But the result should look much better. For example:

Using host libthread_db library "/lib/libthread_db.so.1".
[Thread debugging using libthread_db enabled]
[New Thread -1232783168 (LWP 7604)]
[KCrash handler]
#6 0x0806be76 in TreeMapItem::parent (this=0x0)
at /home/bram/KDE/kde3/kdeaddons/konq-plugins/fsview/treemap.h:285
#7 0x08065fea in TreeMapItemList::compareItems (this=0xbfec04a8, item1=0x0,
item2=0x0)
at /home/bram/KDE/kde3/kdeaddons/konq-plugins/fsview/treemap.cpp:720
#8 0xb7281619 in QGList::operator== () from /usr/qt/3/lib/libqt-mt.so.3
#9 0x0806d498 in QPtrList<TreeMapItem>::operator== (this=0xbfec04a8,
list=@0xbfec0468) at /usr/qt/3/include/qptrlist.h:74
#10 0x08062e18 in TreeMapWidget::mousePressEvent (this=0xbfec03ac,
e=0xbfebff1c)
at /home/bram/KDE/kde3/kdeaddons/konq-plugins/fsview/treemap.cpp:1840
#11 0xb7004a63 in QWidget::event () from /usr/qt/3/lib/libqt-mt.so.3
#12 0xb6f6bca7 in QApplication::internalNotify ()
from /usr/qt/3/lib/libqt-mt.so.3
#13 0xb6f6ca88 in QApplication::notify () from /usr/qt/3/lib/libqt-mt.so.3
#14 0xb7725a84 in KApplication::notify (this=0xbfec055c, receiver=0xbfec03ac,
event=0xbfebff1c)
at /home/bram/KDE/kde3/kdelibs/kdecore/kapplication.cpp:550
#15 0xb6f0bfd2 in QETWidget::translateMouseEvent ()
from /usr/qt/3/lib/libqt-mt.so.3
#16 0xb6f0b8b0 in QApplication::x11ProcessEvent ()
from /usr/qt/3/lib/libqt-mt.so.3
#17 0xb6f1b761 in QEventLoop::processEvents () from /usr/qt/3/lib/libqt-mt.so.3
#18 0xb6f82831 in QEventLoop::enterLoop () from /usr/qt/3/lib/libqt-mt.so.3
#19 0xb6f826b6 in QEventLoop::exec () from /usr/qt/3/lib/libqt-mt.so.3
#20 0xb6f6b72f in QApplication::exec () from /usr/qt/3/lib/libqt-mt.so.3
#21 0x0805181e in main (argc=134673960, argv=0xffffffff)
at /home/bram/KDE/kde3/kdeaddons/konq-plugins/fsview/main.cpp:55

This looks better, right? It shows memory addresses, the source files and line numbers and the parameters passed to functions. Which make it more helpful to the developer where to look for the problem.

{{note|You '''need''' GDB installed to get the backtrace of a crash. Please read the next section to know what GDB is, and how to install it.}}

===Retrieving a backtrace with GDB===

In some cases, it is not possible to create a backtrace with the KDE Crash Dialog. This may be caused by an application which entered an infinite loop, or the crash dialog did not appear at all for some reason. You can try to grab a backtrace with <tt>gdb</tt>, the [http://sourceware.org/gdb/ GNU Debugger]. GDB is widely available through distribution packages.

Invoking GDB differs from the situation. You can run an application from inside gdb, or attach gdb to an already running process. The latter may be useful when an application already has entered an infinite loop. But we will first start with running an application inside gdb. From the shell, run:

$ gdb someKDEapp

The GDB prompt will appear. Note that this does not start the application itself, you should run it by invoking the <tt>run</tt> command:

(gdb) run

This will run the application like you are used to, and you can work with it like normal (it only consumes far more memory and may feel sluggish). Now it's time to reproduce your crash. When you succeed, the application just closes and you should return to your GDB prompt. Now it's time to run the 'backtrace' command:

{{note|Some KDE applications (such as JuK and KTorrent) have special code to ensure that there is only one running instance of the application at a time. For these applications you should type in "run --nofork" at the (gdb) prompt instead of "run" because otherwise gdb will try to debug the wrong process. If you are unsure as to whether to use --nofork just try it. If the application says it's an unknown option you can remove --nofork.}}

(gdb) thread apply all backtrace

This should give a good backtrace which can be posted at the KDE Bugzilla.

In case you want to attach to an existing process, run the following command in the shell:

$ gdb someKDEapp pid

where ''pid'' is the process ID of the process you want to attach to. Once attached, and the process is in an infinite loop, after using the 'backtrace' command again a useful backtrace will appear. You can use 'continue' command to let the application run again and press Ctrl+C in gdb to be able to again enter commands.

===Retrieving a backtrace with Valgrind===

When it comes to crashes, [http://www.valgrind.org Valgrind] is also a useful tool to create a backtrace. It's not a substitution for GDB, but rather a supplement.

When you run an application in valgrind, every piece of memory read or written by the application is being checked. Valgrind will report erroneous memory operations in the standard output or in a log file. Since most crashes are due to an invalid memory read, valgrind can be useful to track down where the problem occurs.

{{note|Valgrind consists of several tools in order to check or profile an application. For this article, we only use memcheck, the default tool when valgrind is being invoked.}}

Like GDB, Valgrind makes running an application much slower, while consuming a lot more resources.

Start the application within valgrind:

$ valgrind --log-file=someKDEapp someKDEapp

Now reproduce the crash. As soon as this happens, the application and valgrind will terminate. What's left is a file named <tt>someKDEapp.pid</tt> where ''pid'' is replaced by the process ID of the valgrind process. The file may list more errors than the one causing the crash. Here's the bit causing the crash which corresponds to the GDB backtrace above:

==23292== Invalid read of size 4
==23292== at 0x806BD9E: TreeMapItem::parent() const (treemap.h:285)
==23292== by 0x8065FB9: TreeMapItemList::compareItems(void*, void*) (treemap.cpp:720)
==23292== by 0x50AC618: QGList::operator==(QGList const&) const (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== by 0x806D3BF: QPtrList<TreeMapItem>::operator==(QPtrList<TreeMapItem> const&) const (qptrlist.h:74)
==23292== by 0x8062DE7: TreeMapWidget::mousePressEvent(QMouseEvent*) (treemap.cpp:1840)
==23292== by 0x4E2FA62: QWidget::event(QEvent*) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== by 0x4D96CA6: QApplication::internalNotify(QObject*, QEvent*) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== by 0x4D97A87: QApplication::notify(QObject*, QEvent*) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== by 0x4809AC3: KApplication::notify(QObject*, QEvent*) (kapplication.cpp:550)
==23292== by 0x4D36FD1: QETWidget::translateMouseEvent(_XEvent const*) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== by 0x4D368AF: QApplication::x11ProcessEvent(_XEvent*) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== by 0x4D46760: QEventLoop::processEvents(unsigned) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
==23292== Address 0x2C is not stack'd, malloc'd or (recently) free'd

But to be sure, just attach the whole log file to the crash report.

User:Panda84

2009-03-23T20:26:18Z

Panda84: Wiki structure moved and Useful crash report created.

== whoami ==

I'm an Italian KDE user willing to become a KDE developer sooner or later. :)

I thought that the first step to become a developer was reading developer's documentation... and then why not translate it after reading?

== DONE ==

Pages translated:
* 18/07/2008 - [[Help:Wiki_Translation_(it)|Help : Wiki translation]] - let's start from the beginning, am I right? :)
* 15/08/2008 - [[Help:Contents_(it)|Help : Contents]]
* 16/08/2008 - [[Help:Contribute_(it)|Help : Contribute]]
* 28/09/2008 - [[Help:Wiki_Structure_(it)|Help : Wiki Structure]]

== WORK IN PROGRESS ==

* 23/03/2009 - [[User:Panda84/Development/Tutorials/Debugging/How_to_create_useful_crash_reports_(it)|Debugging : How to create useful crash report]]

== TODO ==

I'll translate all pages that'll come on my way!

Help:Wiki Structure (it)

2009-03-23T20:14:46Z

Panda84: User:Panda84/Help:Wiki Structure (it) moved to Help:Wiki Structure (it): Looks like the page is ok. I should have moved it long time ago...

{{Template:I18n/Language Navigation Bar|Help:Wiki Structure}}

Questa pagina illustra i metodi utilizzati per mantenere il wiki degli sviluppatori KDE.

== Pagine radice ==
Le pagine più importanti in questo wiki sono le pagine radice (in ordine alfabetico):

;[[Contribute]]
;[[Development]]
:[[Development/Architecture]]
:[[Development/FAQs]]
:[[Development/Further Information]]
:[[Development/Guidelines]]
:[[Development/Languages]]
:[[Development/Tools]]
:[[Development/Tutorials]]
;[[Getting Started]]
;[[ISV]]
;[[Policies]]
;[[Projects]]
;[[Schedules]]
;[[KDE System Administration]]

Tutte le altre pagine o articoli appartengono ad una di queste pagine (o ad una delle loro sottopagine), ciò significa che facciamo ampio uso di sottopagine per mantenere la struttura e la gerarchia per non perdere la visuale d'insieme.

=== Sottopagine ===
Una sottopagina è una relazione genitore-figlio. Nel seguente esempio '''Development''' è il ''genitore'' di '''Tutorials''', o, per dirla nel modo opposto la pagina '''Tutorials''' è una sottopagina (o un figlio) di '''Development'''.

[[Development/Tutorials]]

Usare sottopagine ha svariati vantaggi:
* forniscono in modo automatico una '''gerarchia''' implicita nell'URL stesso
* i '''link all'indietro''' generati automaticamente forniscono una facile navigazione

Ad esempio, dai uno sguardo alla pagina
[[Development/Architecture/KDE3/Library Structure]]
puoi notare i seguenti link all'inizio della pagina:
< [[Development]] | [[Development/Architecture|Architecture]] | [[Development/Architecture/KDE3|KDE3]]

== Categorie ==

In breve, una [http://meta.wikimedia.org/wiki/Help:Category categoria] è un '''tag''' che appare alla fine di un articolo. In quanto tali, le categorie forniscono un'indicizzazione automatica che è utile come indice dei contenuti. Assieme ai link e ai template aiutano molto a strutturare un progetto.

* [[Special:Categories|Lista di categorie]]
* [[Special:Unusedcategories|Lista di categorie non utilizzate]] - Sentiti libero di usarle

Assicurati di leggere la pagina della categoria (ad esempio [[:Category:Documentation]]) prima di aggiungerla come tag in modo da usarla in modo corretto.

== Pagine speciali importanti ==
Ci sono varie pagine speciali che aiutano a mantenere pulito il wiki:

; Problemi che andrebbero sistemati prima possibile
:[[Special:Lonelypages]]
:[[Special:BrokenRedirects]]
:[[Special:DoubleRedirects]]

; Problemi che andrebbero risolti nel tempo
:[[Special:Wantedpages]]
:[[Special:Wantedcategories]]

[[Category:Policies]]

User:Panda84/Help:Wiki Structure (it)

2009-03-23T20:14:46Z

Panda84: User:Panda84/Help:Wiki Structure (it) moved to Help:Wiki Structure (it): Looks like the page is ok. I should have moved it long time ago...

#REDIRECT [[Help:Wiki Structure (it)]]

User talk:Dhaumann

2008-10-06T15:59:03Z

Panda84: Added a question about Wiki_Structure

Its fine to delete the kdesvn-build page. I will merge my content into the existing page. Also, I will also modify the link from the Getting Started page to point to the existing kdesvn-build page.
[[User:Kunalthakar|Kunalthakar]] 19:51, 7 November 2007 (CET)

== Thanks ==
Thanks for the information.. If I got more questions, can I ask you then?
: Of course -- [[User:Dhaumann|Dhaumann]]

== Movinh Content ==
Hi, Thanks for movinh Qualig?ty team to a another place.. I did ngot know where to place it.. I'm going to move more from quality.kde.org, should I move it to the same folder or what?

== Title Translation ==

Hi guy !!!
I would like to know if menu bar translation is possible... If true, how could I do this?
Thank you...

:You can use the template <nowiki>{{DISPLAYTITLE:foo}}</nowiki>, where 'foo' is the translation. However, the display title reflects the wiki link, that's why a text "link to this page as <nowiki>[[...]]</nowiki>" will appear then. --[[User:Dhaumann|Dhaumann]] 15:40, 18 June 2007 (CEST)

::Actually not, I have hidden that text with display:none for on-screen printing. One bug though: When using DISPLAYTITLE, the <title> tag is not filled for some reason... --[[User:Danimo|Danimo]] 16:33, 18 June 2007 (CEST)

:::Damn... If you need help with this, you can ask me as you want for help... ;) --[[User:Fatalerrors|Fatalerrors]] 10:52, 20 June 2007 (CEST)

----

Hi, Dhaumann, can you read and write Chinese? Cool! --[[User:Liangqi|Liangqi]] 23:00, 18 June 2007 (CEST)

: Unfortunately no. I can't read nor write it. But I still try my best to fix links in a language where I mostly see squares :-) --[[User:Dhaumann|Dhaumann]] 23:22, 18 June 2007 (CEST)

:: I see, I had found it in the diff. Thanks. I had mentioned this link problem in our mailing list. --[[User:Liangqi|Liangqi]] 11:36, 20 June 2007 (CEST)

== Thanks ==

Hi, Dhaumann, thanks for links fixes.
I had fixed the link you were talking about.
Thanks a lot.
--[[User:Powerfox|Powerfox]] 19:15, 31 July 2007 (CEST)

== Trank you ==

Thank you a lot for fixing the links of galician tech base ;).

==Getting_Started/Build/KDE4_(bn_IN) ==
Thank you for explaining me. I misunderstood the previous message of yours. Thanks again for pointing me to the right direction :)

== Sorting in feature list ==

Why did you manually move (to sort) the stuff in the feature list?
It totally breaks the history... :(

IMHO it should had been some kind of automatic sorting... or this sadly proves once again the old system was quite better..

--[[user:Pino|pino]] 11:32, 17 March 2008 (CET)

== Do me a favour... ==

Could you somehow take care of [[Development/Tutorials/Phonon/Introduction]]? It's in no usable state and I would recommend deleting it, and rather directly point a link to the API. I'm asking here, cause you once moved the page. --[[Special:Contributions/88.66.153.231|88.66.153.231]] 00:44, 3 June 2008 (CEST)

== Wiki Structure - sub-pages ==

The example [[Help:Wiki_Structure#Sub-pages|here]] is not valid anymore (or at least there's nothing like that "on the very top of the page"). What's better to do with it? Thanks.

Help:Wiki Structure (it)

2008-10-06T15:35:51Z

Panda84: Page fully translated

User:Panda84

2008-09-28T20:53:07Z

Panda84: Added work in progress section

== whoami ==

I'm an Italian KDE user willing to become a KDE developer sooner or later. :)

I thought that the first step to become a developer was reading developer's documentation... and then why not translate it after reading?

== DONE ==

Pages translated:
* 18/07/2008 - [[Help:Wiki_Translation_(it)|Help : Wiki translation]] - let's start from the beginning, am I right? :)
* 15/08/2008 - [[Help:Contents_(it)|Help : Contents]]
* 16/08/2008 - [[Help:Contribute_(it)|Help : Contribute]]

== WORK IN PROGRESS ==

* 28/09/2008 - [[User:Panda84/Help:Wiki_Structure_(it)|Help : Wiki Structure]]

== TODO ==

I'll translate all pages that'll come on my way!

Help:Wiki Structure (it)

2008-09-28T20:44:58Z

Panda84: Working copy, translation in progress.

{{Template:I18n/Language Navigation Bar|Help:Wiki Structure}}

Questa pagina illustra i metodi utilizzati per mantenere il wiki degli sviluppatori KDE.

== Pagine radice ==
Le pagine più importanti in questo wiki sono le pagine radice (in ordine alfabetico):

;[[Contribute]]
;[[Development]]
:[[Development/Architecture]]
:[[Development/FAQs]]
:[[Development/Further Information]]
:[[Development/Guidelines]]
:[[Development/Languages]]
:[[Development/Tools]]
:[[Development/Tutorials]]
;[[Getting Started]]
;[[ISV]]
;[[Policies]]
;[[Projects]]
;[[Schedules]]
;[[KDE System Administration]]

Tutte le altre pagine o articoli appartengono ad una di queste pagine (o ad una delle loro sottopagine), ciò significa che facciamo ampio uso di sottopagine per mantenere la struttura e la gerarchia per non perdere la visuale d'insieme.

=== Sottopagine ===
Una sottopagina è una relazione genitore-figlio. Nel seguente esempio '''Development''' è il ''genitore'' di '''Tutorials''', o, per dirla nel modo opposto la pagina '''Tutorials''' è una sottopagina (o un figlio) di '''Development'''.

[[Development/Tutorials]]

Using sub-pages has several advantages:
* they automatically provide us with a '''hierarchy''' which is reflected in the URL itself
* automatically generated ''backlinks'' provide easy navigation

As an example, look at the page
[[Development/Architecture/KDE3/Library Structure]]
you can see following the links on the very top of the page:
< [[Development]] | [[Development/Architecture|Architecture]] | [[Development/Architecture/KDE3|KDE3]]

== Categories ==
In short, a [http://meta.wikimedia.org/wiki/Help:Category category] is a '''tag''' which appears at the very bottom of an article. As such, categories provide automatic indexes that are useful as tables of contents. Together with links and templates they help structure a project.

* [[Special:Categories|List of categories]]
* [[Special:Unusedcategories|List of unused categories]] - Feel free to use them

Be sure to read the category page (e.g. [[:Category:Documentation]]) before tagging a page with it to make sure you're using it correctly.

== Important special pages ==
There are several special pages which help us to maintain a clean wiki:

; Issues which should be fixed as soon as possible
:[[Special:Lonelypages]]
:[[Special:BrokenRedirects]]
:[[Special:DoubleRedirects]]

; Issues which should be fixed in time
:[[Special:Wantedpages]]
:[[Special:Wantedcategories]]

[[Category:Policies]]

User:Panda84

2008-08-16T10:04:43Z

Panda84: Added a new translated page.

Help:Contents (it)

2008-08-16T10:02:53Z

Panda84: Corretto link: Help:Contribute è stata tradotta in italiano.

{{Template:I18n/Language Navigation Bar|Help:Contents}}

Prima di cominciare ad aggiungere o cambiare i contenuti per favore leggi gli articoli riguardo:
* [[Help:Contribute_(it)|Contribuire a TechBase]]
* [[Help:Wiki Structure|Struttura del Wiki]]
* [[Help:Wiki Translation_(it)|Traduzione in altre lingue]]
* [[KDE_TechBase:Migrate_content|Migrare contenuti]]
* [[KDE_TechBase:Contributors|Lista di contributori attivi]] che si possono contattare.

== Sintassi del Wiki ==
Per fare pratica con la sintassi di MediaWiki leggere:
* http://en.wikipedia.org/wiki/Help:Editing
* http://meta.wikimedia.org/wiki/Help:Table
* http://en.wikipedia.org/wiki/Wikipedia:Extended_image_syntax
* http://en.wikipedia.org/wiki/Help:Magic_words

I comandi più importanti sono riassunti nella [http://en.wikipedia.org/wiki/Wikipedia:Cheatsheet guida rapida di Wikipedia]. Informazioni su come migrare i contenuti [[KDE TechBase:Migrate_content|possono essere trovate qui]].

== Consigli ==
; Evidenziazione della sintassi
: Inserisci i tuoi frammenti di codice C++ Qt/KDE tra <code cpp>, <code cpp n>, <code qt> e </code> per ottenere l'evidenziazione della sintassi (cpp == c++, qt == qt) e la numerazione delle righe (n). Sostituisci "cpp" con il relativo linguaggio usato, ad esempio "rubyqt" per Ruby e "pythonqt" per Python (al momento non ancora disponibili). Usa "ini" per i file .desktop e "xml" per i file XML.

== Nuovi template ==
Per avere la lista delle pagine che usano un dato template andare alla corrispondente pagina template (ad esempio [[Template:movepage]]) e cliccare su "''Puntano qui''" nella toolbox a sinistra.

; [[Template:movepage|<nowiki>{{movepage|url}}</nowiki>]]
: Usare questo template per segnare una pagina come non completata.

; [[Template:Improve|<nowiki>{{improve|explanation}}</nowiki>]]
: Pagine che devono essere ripulite, contengono sezioni vuote e/o liste di cose da fare sono segnate con questo template. Puoi aggiungere una spiegazione se vuoi (facoltativo).

; [[Template:tip|<nowiki>{{tip|text}}</nowiki>]]
: Usa questo template per aggiungere un consiglio al lettore.

; [[Template:note|<nowiki>{{note|text}}</nowiki>]]
: Usa questo template per aggiungere una nota esplicativa.

; [[Template:warning|<nowiki>{{warning|text}}</nowiki>]]
: Usa questo template per aggiungere un avvertimento.

; [[Template:qt|<nowiki>{{qt|class-name}}</nowiki>]] e [[Template:qt3|<nowiki>{{qt3|class-name}}</nowiki>]]
: Usa questo template per generare un link ad una classe Qt, ad esempio QWidget. Per una classe Qt3 usa <nowiki>{{qt3|class-name}}</nowiki>

; [[Template:class|<nowiki>{{class|class-name}}</nowiki>]]
: Usa questo template per generare un link a una classe KDE, ad esempio KDialog.

; [[Template:path|<nowiki>{{path|path-or-filename}}</nowiki>]]
: Usa questo template per percorsi e nomi di file, in questo modo avranno tutti uno stile uniforme.

; [[Template:bug|<nowiki>{{bug|123456}}</nowiki>]]
: Usa questo template per creare in automatico un link al bugzilla di KDE.

; [[Template:KDE3|<nowiki>{{KDE3}}</nowiki>]]
: Usa questo template per segnare il contenuto di una pagina valido anche per KDE 3. Non segnare in questo modo pagine che non hanno contenuto tecnologico. Per contenuti relativi a KDE 4 usare <nowiki>[[Category:KDE4]]</nowiki>.

; [[Template:TutorialBrowser|<nowiki>{{TutorialBrowser|series|name|pre|next|reading}}</nowiki>]]
: Un template per la navigazione dei tutorial.

; [[Template:Box|<nowiki>{{Box|caption|text|width|float}}</nowiki>]]
: Usa questo template per creare un riquadro con un etichetta ed un testo. Il parametro della larghezza è opzionale e può essere specificato sia in maniera assoluta (ad esempio 400px) sia in maniera relativa (ad esempio 50%). L'ultimo parametro è il valore della posizione, è anch'esso opzionale ed è impostato di default come centrato.

Help:Contribute (it)

2008-08-16T10:00:14Z

Panda84: First italian translation - Prima traduzione in italiano

{{Template:I18n/Language Navigation Bar|Help:Contribute}}

Il tuo contributo al wiki di KDE TechBase è ben accetto. Per ottenere contenuti e articoli di alta qualità ci sono un po' di linee guida che devi rispettare. Questa è una breve introduzione a come modificare e contribuire al wiki.

== I contenuti di KDE TechBase ==

Il wiki di KDE TechBase è pensato per contenere informazioni tecniche relative a KDE, ad esempio:
* informazioni per gli sviluppatori (ad esempio [[Development/Tutorials_(it)|tutorial]])
* [[KDE System Administration|amministrazione di sistema con KDE]]
* regole e piani di lavoro
* eccetera

Ulteriori dettagli possono essere trovati nell'articolo sulla [[Help:Wiki Structure|struttura del wiki]].

[http://docs.kde.org Documentazione per l'utente] o [http://api.kde.org documentazione delle API] ''non'' vanno aggiunte qui. Per questioni non tecniche usare [http://wiki.kde.org il wiki di KDE].

=== Dove inserire i nuovi articoli ===

Il wiki di KDE TechBase usa sottopagine. Dai una rapida occhiata all'articolo riguardo la [[Help:Wiki Structure|struttura del wiki]]. Per farla breve: non aggiungere a caso pagine nel livello più alto.

È possibile tradurre articoli di KDE TechBase in altre lingue. Leggi l'articolo riguardo la [[Help:Wiki Translation_(it)|traduzione del wiki]] per ulteriori dettagli.

=== La procedura ===

Vuoi aggiungere nuovo contenuto. Per mantenere alto lo standard di qualità per favore prima crea la pagina dell'articolo nella tua pagina personale (ad esempio User:foo/My Article). Una volta che è pronta, discuti l'articolo con altri sviluppatori e ricontrollala. Quando hai trovato il posto adatto dove inserirla sposta la pagina.

== Le basi della modifica ==

Nel wiki di KDE TechBase tutti gli utenti registrati possono modificare il contenuto e la struttura.

=== Regole di revisione e convenzioni ===

Assicurati che l'informazione che aggiungi sia rilevante al proposito specifico del wiki, in caso contrario i tuoi contenuti potrebbero essere rimossi. Puoi sempre usare le [[Help:Talk page|pagine di ''Discussione'' o ''Talk'']] per fare domande o assicurarti che la tua idea venga accettata. Per favore assicurati anche che i tuoi contributi non violino alcuna licenza.

=== Cominciare a modificare ===

Per cominciare a modificare una pagina di [[Main Page|KDE TechBase]] clicca su '''Modifica''' nella parte superiore del wiki. Verrai portato alla pagina di modifica: qui avrai a disposizione un'area di testo contenente il ''wikitext'' ovvero il codice modificabile da cui il server produce poi la pagina finale visibile all'utente. ''Se vuoi solo fare esperimenti puoi esercitarti nella [[Sandbox|sandbox]], non farlo qui''.

=== Inserire le modifiche ===

Per cominciare è sufficiente inserire il proprio testo. Per migliorare l'aspetto e l'ordine è necessario usare gli appositi comandi wiki, ad esempio per creare dei link o dare un'impaginazione migliore. Per favore usa lo stile utilizzato anche negli altri articoli del wiki. Se segui queste semplici regole i tuoi contributi saranno più utili in quanto non richiederanno successive ripuliture.

=== Riassumere le modifiche ===

Scrivi un breve riassunto nel piccolo campo sotto l'area di testo, ad esempio "Corretto un errore di ortografia."

=== Anteprima prima di salvare ===

Quando hai finito clicca su '''Visualizza anteprima''' per vedere come si presenteranno le tue modifiche '''prima''' di renderle permanenti. Ripeti il processo di modifica e anteprima finchè non sei soddisfatto, poi clicca su '''Salva la pagina''' e le tue modifiche saranno immediatamente applicate all'articolo.

== Pagina dei comandi Wiki ==

La wikipedia fornisce una rapida introduzione alla principale sintassi mediawiki. Per favore leggi l'apposita [http://en.wikipedia.org/wiki/Wikipedia:How_to_edit_a_page pagina di aiuto].

User:Panda84

2008-08-15T08:46:54Z

Panda84: Added a new translated paged.

Help:Contents (it)

2008-08-15T08:37:16Z

Panda84: First italian translation - Prima traduzione in italiano

{{Template:I18n/Language Navigation Bar|Help:Contents}}

Prima di cominciare ad aggiungere o cambiare i contenuti per favore leggi gli articoli riguardo:
* [[Help:Contribute|Contribuire a TechBase]]
* [[Help:Wiki Structure|Struttura del Wiki]]
* [[Help:Wiki Translation_(it)|Traduzione in altre lingue]]
* [[KDE_TechBase:Migrate_content|Migrare contenuti]]
* [[KDE_TechBase:Contributors|Lista di contributori attivi]] che si possono contattare.

== Sintassi del Wiki ==
Per fare pratica con la sintassi di MediaWiki leggere:
* http://en.wikipedia.org/wiki/Help:Editing
* http://meta.wikimedia.org/wiki/Help:Table
* http://en.wikipedia.org/wiki/Wikipedia:Extended_image_syntax
* http://en.wikipedia.org/wiki/Help:Magic_words

I comandi più importanti sono riassunti nella [http://en.wikipedia.org/wiki/Wikipedia:Cheatsheet guida rapida di Wikipedia]. Informazioni su come migrare i contenuti [[KDE TechBase:Migrate_content|possono essere trovate qui]].

== Consigli ==
; Evidenziazione della sintassi
: Inserisci i tuoi frammenti di codice C++ Qt/KDE tra <code cpp>, <code cpp n>, <code qt> e </code> per ottenere l'evidenziazione della sintassi (cpp == c++, qt == qt) e la numerazione delle righe (n). Sostituisci "cpp" con il relativo linguaggio usato, ad esempio "rubyqt" per Ruby e "pythonqt" per Python (al momento non ancora disponibili). Usa "ini" per i file .desktop e "xml" per i file XML.

== Nuovi template ==
Per avere la lista delle pagine che usano un dato template andare alla corrispondente pagina template (ad esempio [[Template:movepage]]) e cliccare su "''Puntano qui''" nella toolbox a sinistra.

; [[Template:movepage|<nowiki>{{movepage|url}}</nowiki>]]
: Usare questo template per segnare una pagina come non completata.

; [[Template:Improve|<nowiki>{{improve|explanation}}</nowiki>]]
: Pagine che devono essere ripulite, contengono sezioni vuote e/o liste di cose da fare sono segnate con questo template. Puoi aggiungere una spiegazione se vuoi (facoltativo).

; [[Template:tip|<nowiki>{{tip|text}}</nowiki>]]
: Usa questo template per aggiungere un consiglio al lettore.

; [[Template:note|<nowiki>{{note|text}}</nowiki>]]
: Usa questo template per aggiungere una nota esplicativa.

; [[Template:warning|<nowiki>{{warning|text}}</nowiki>]]
: Usa questo template per aggiungere un avvertimento.

; [[Template:qt|<nowiki>{{qt|class-name}}</nowiki>]] e [[Template:qt3|<nowiki>{{qt3|class-name}}</nowiki>]]
: Usa questo template per generare un link ad una classe Qt, ad esempio QWidget. Per una classe Qt3 usa <nowiki>{{qt3|class-name}}</nowiki>

; [[Template:class|<nowiki>{{class|class-name}}</nowiki>]]
: Usa questo template per generare un link a una classe KDE, ad esempio KDialog.

; [[Template:path|<nowiki>{{path|path-or-filename}}</nowiki>]]
: Usa questo template per percorsi e nomi di file, in questo modo avranno tutti uno stile uniforme.

; [[Template:bug|<nowiki>{{bug|123456}}</nowiki>]]
: Usa questo template per creare in automatico un link al bugzilla di KDE.

; [[Template:KDE3|<nowiki>{{KDE3}}</nowiki>]]
: Usa questo template per segnare il contenuto di una pagina valido anche per KDE 3. Non segnare in questo modo pagine che non hanno contenuto tecnologico. Per contenuti relativi a KDE 4 usare <nowiki>[[Category:KDE4]]</nowiki>.

; [[Template:TutorialBrowser|<nowiki>{{TutorialBrowser|series|name|pre|next|reading}}</nowiki>]]
: Un template per la navigazione dei tutorial.

; [[Template:Box|<nowiki>{{Box|caption|text|width|float}}</nowiki>]]
: Usa questo template per creare un riquadro con un etichetta ed un testo. Il parametro della larghezza è opzionale e può essere specificato sia in maniera assoluta (ad esempio 400px) sia in maniera relativa (ad esempio 50%). L'ultimo parametro è il valore della posizione, è anch'esso opzionale ed è impostato di default come centrato.

Help:Contents

2008-08-15T08:12:15Z

Panda84: Fixed typo "tempate"

{{Template:I18n/Language Navigation Bar|Help:Contents}}

Before you start to add or change content, please read the articles about the
* [[Help:Contribute|Contribute to TechBase]]
* [[Help:Wiki Structure|Wiki Structure]]
* [[Help:Wiki Translation|Translation into other Languages]]
* [[KDE_TechBase:Migrate_content|Migrate Content]]
* [[KDE_TechBase:Contributors|List of active contributors]], also contact points

== Wiki Syntax ==
To get started with the MediaWiki syntax, read
* http://en.wikipedia.org/wiki/Help:Editing
* http://meta.wikimedia.org/wiki/Help:Table
* http://en.wikipedia.org/wiki/Wikipedia:Extended_image_syntax
* http://en.wikipedia.org/wiki/Help:Magic_words

The most important commands are summarized in the [http://en.wikipedia.org/wiki/Wikipedia:Cheatsheet Wikipedia Cheatsheet]. Information about how to migrate content [[KDE TechBase:Migrate_content|can be found here]].

== Tips ==
; Syntax highlighting
: Wrap your C++ Qt/KDE code snippets in <code cpp>, <code cpp n>, <code qt> and </code> to get syntax highlighting (cpp == c++, qt == qt) and numbered lines (n). Replace "cpp" with the language used, e.g. rubyqt for Ruby and pythonqt for Python (soon). Use "ini" for .desktop files, "xml" for XML files.

== New Templates ==
To get a list of pages using a template, go to corresponding template page (e.g. [[Template:movepage]]) and click "''What links here''" in the toolbox.

; [[Template:movepage|<nowiki>{{movepage|url}}</nowiki>]]
: Use this template to mark a page as not finished.

; [[Template:Improve|<nowiki>{{improve|explanation}}</nowiki>]]
: Pages which need cleanups or contain empty sections and/or todos are marked with this template. Add an explanation if you want (optional)

; [[Template:tip|<nowiki>{{tip|text}}</nowiki>]]
: Use this template to add a tip for the reader.

; [[Template:note|<nowiki>{{note|text}}</nowiki>]]
: Use this template to add an explanatory note.

; [[Template:warning|<nowiki>{{warning|text}}</nowiki>]]
: Use this template to add a warning.

; [[Template:qt|<nowiki>{{qt|class-name}}</nowiki>]] and [[Template:qt3|<nowiki>{{qt3|class-name}}</nowiki>]]
: Use this template to generate a link to a Qt class, e.g. QWidget. For Qt3 classes use <nowiki>{{qt3|class-name}}</nowiki>

; [[Template:class|<nowiki>{{class|class-name}}</nowiki>]]
: Use this template to generate a link to a KDE class, e.g. KDialog.

; [[Template:path|<nowiki>{{path|path-or-filename}}</nowiki>]]
: Use this template for paths and filenames, this way all of them have a consistent style.

; [[Template:bug|<nowiki>{{bug|123456}}</nowiki>]]
: Use this template to automatically create a link to KDE's bugzilla.

; [[Template:KDE3|<nowiki>{{KDE3}}</nowiki>]]
: Use this template to mark the content of a page as applicable for either KDE 3. Don't tag technology agnostic pages. For KDE4 content, use <nowiki>[[Category:KDE4]]</nowiki>.

; [[Template:TutorialBrowser|<nowiki>{{TutorialBrowser|series|name|pre|next|reading}}</nowiki>]]
: A template for tutorial navigation

; [[Template:Box|<nowiki>{{Box|caption|text|width|float}}</nowiki>]]
: Use this template to create a box with a caption and a text. The width parameter is optional and can be specified absolute (400px) or relative (50%). The last parameter is the float value, which is also optional and defaults to center.

User:Panda84

2008-07-18T20:14:47Z

Panda84: First version of my personal page.

KDE TechBase:Contributors

2008-07-18T20:02:50Z

Panda84: Added myself to the italian team

Welcome to the contributors page.

'''This site contains a list of ''active'' contributors. It should help to build teams which maintain KDE TechBase's content. If you have questions about KDE TechBase you can ask/email the corresponding person.'''

Please add yourself to the list where appropriate. If you are inactive, please remove yourself again.

== Administrators ==

This is a list of KDE TechBase administrators.

* [[User:Danimo|Danimo]]
* [[User:Dhaumann|Dhaumann]], <dhaumann at kde dot org>

== Reviewers and Article Writers ==

If you are continuously reviewing KDE TechBase changes or writing articles add yourself to the list.

* [[User:Dhaumann|Dhaumann]], <dhaumann at kde dot org>
* [[User:Milliams|Milliams]]
* name, <email>

== Translation Teams ==

KDE TechBase is [[Help:Wiki Translation|translated]] into many languages. If you translate pages please add yourself to the right translation team.

=== Chinese(simplified) Team ===
* [[User:Liangqi|Liangqi]], cavendish.qi at gmail dot com
* name, <email>

=== Spanish Team ===
* [[User:Martin J. Ponce|Martin J. Ponce]], mjp_ttc at yahoo dot com
* [[User:Aikurn|L. H. Urigüen]], aikurn at gmail dot com
* name, <email>

=== German Team ===
* [[User:DrSlowDecay|DrSlowDecay]], kde at metalhorde dot de
* [[User:Rememberme|rememberme]] redict dot info at gmx dot net
* [[User:sschloenvoigt|Steffen Schloenvoigt]], steffen at schloenvoigt dot de
* name, <email>

=== Italian Team ===
* [[User:Thunder Teaser|Thunder Teaser]], totokid at gmail dot com
* [[User:Panda84|Panda84]], panda84 at inwind dot it
* name, <email>

=== Tamil Team ===
* [[User:Shriramadhas|Shriramadhas]], shriramadhas at gmail dot com
* name, <email>

=== ... Team ===
* name, <email>

Help:Wiki Translation (it)

2008-07-18T19:58:00Z

Panda84: First italian translation - Prima traduzione in italiano

{{Template:I18n/Language Navigation Bar|Help:Wiki_Translation}}
Questo articolo descrive come '''tradurre articoli in altre lingue'''. Si prega di leggere anche l'ultima sezione relativa alle [[#Note importanti|note importanti]].

== Passo 1: Abbreviazioni delle lingue ==

Supponiamo ad esempio di voler tradurre la seguente pagina in tedesco:
* [[Development/Tutorials]]
L'abbreviazione per la lingua tedesca è '''de''', quindi tutti gli articoli in tale lingua termineranno con " (de)" (con uno spazio all'inizio).

Riferimento: [http://www.opticentre.net/FAQ/Languages/List-of-language-abbreviations/ lista delle abbreviazioni delle lingue].

== Passo 2: Creare l'articolo ==

Alcune volte un collegamento nella barra di scelta delle lingue è già presente. In tal caso è sufficiente cliccare sul link per tradurre nella relativa lingua. In caso contrario è necessario creare l'articolo manualmente:
* [[Development/Tutorials (de)]]
'''Come contenuto iniziale è consigliabile usare il contenuto della pagina in inglese corrispondente'''. In questo modo nessun contenuto va perso e altri lettori possono contribuire alla traduzione.

== Passo 3: Barra di scelta delle lingue ==

L'articolo deve contenere la seguente riga di codice come template al fine di mostrare la barra di scelta delle lingue:
* <nowiki>{{Template:I18n/Language Navigation Bar|Development/Tutorials}}</nowiki>
Questa riga si espande nella barra di scelta delle lingue per l'articolo <tt>Development/Tutorials</tt>. Notare che la riga non contiene le abbreviazioni delle lingue.

== Passo 4: Lingue mancanti? ==

Se la lingua non è presente nella barra di scelta è necessario cercare manualmente l'abbreviazione relativa (vedere Passo 1). Nell'esempio precedente l'abbreviazione era " (de)".

Modificare la pagina [[Template:I18n/Language Navigation Bar]] e aggiungere una riga per la lingua in cui si vuole tradurre:
<nowiki><span lang="de">[[{{{1}}}_(de)|Deutsch]]</span></nowiki>
Sostituire 'de' con l'abbreviazione della lingua corretta e inserire il relativo nome completo.

== Note importanti ==

Dato che il wiki usa [[Help:Wiki Structure|sottopagine]] è probabile che i traduttori possano incorrere nel seguente problema.

Supponiamo esistano le seguenti pagine:
1. Development/Tutorials
2. Development/Tutorials/Debugging
Supponiamo inoltre che si voglia tradurre la pagina (1) in tedesco (suffisso ''de'').

La pagina finale sarà
3. Development/Tutorials_(de)
Il contenuto inglese di (2) usa link relativi come <tt>/Debugging</tt>. Tradurre ''Debugging'' in (3) potrebbe causare i seguenti errori:
Development/Tutorials_(de)/Debugging # sbagliato, o
Development/Tutorials_(de)/Debugging_(de) # sbagliato
'''Questo è un errore.'''

La regola è che la l'abbreviazione della lingua deve apparire sempre alla fine dell'articolo, ad esempio il '''link corretto''' dovrebbe essere:
Development/Tutorials/Debugging_(de)
Quindi è bene assicurarsi di adattare ovunque i link nell'articolo a percorsi assoluti (cioè nessuna barra '/' all'inizio nei link del wiki).

== Controllo qualità ==

Gli amministratori e contributori fanno del loro meglio per tenere d'occhio il contenuto, ma con le lingue straniere questo può essere difficoltoso. Sarebbe bene '''aggiungersi alla lista di osservazione''' (è sufficiente cliccare su ''Segui'' in alto a destra). In questo modo verranno notificate via email tutte le modifiche all'articolo. Questo aiuta a mantenere il wiki pulito ad esempio dallo spam, cosa che sfortunatamente è già capitata.

È altresì consigliato '''aggiungersi al [[KDE_TechBase:Contributors#Translation_Teams|team di traduzione]]'''.