Development/Tutorials/Debugging/How to create useful crash reports (it): Difference between revisions

    From KDE TechBase
    m (Prova di salvataggio)
    (Sezione backtrace tradotta.)
    Line 25: Line 25:
    === Backtrace ===
    === 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''':  
    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)
      (no debugging symbols found)
    Line 52: Line 52:
      0xffffe410 in __kernel_vsyscall ()
      0xffffe410 in __kernel_vsyscall ()
      #0  0xffffe410 in __kernel_vsyscall ()
      #0  0xffffe410 in __kernel_vsyscall ()
      #1  0xb6a1210b in ?? () from /lib/tls/i686/cmov/libpthread.so.0
      #1  0xb6a1210b in ?? () from /lib/tls/i686/cmov/libpthread.so.0
      #2  0xb6a85afe in ?? () from /usr/lib/libX11.so.6
      #2  0xb6a85afe in ?? () from /usr/lib/libX11.so.6
      #3  0x00000003 in ?? ()
      #3  0x00000003 in ?? ()
      #4  0x082149c0 in ?? ()
      #4  0x082149c0 in ?? ()
      #5  0x00003ffc in ?? ()
      #5  0x00003ffc in ?? ()
      #6  0x00000000 in ?? ()
      #6  0x00000000 in ?? ()


    But no worries, with some modifications you can create full blown backtraces for KDE applications.  
    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 ===
    ===Preparing your KDE packages===


    If your distribution has debugging-enabled packages, install them.  
    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:  
    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
      #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.  
    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.  
    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:  
    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). <!--*'''Fedora''' ???-->  
    *'''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].  
    <!--*'''Fedora''' ???-->
    *'''Gentoo''' - Gentoo has its [http://www.gentoo.org/proj/en/qa/backtraces.xml own document] describing how to proceed.  
    *'''FreeBSD ports''' - Please refer to the [http://freebsd.kde.org/faq.php#AKDEapplicationcrashedandIwanttofileabugreportathttpbugskdeorgbutthebacktraceintheKDECrashManagerisuselessWhatcanIdo KDE on FreeBSD FAQ].
    *'''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.  
    *'''Gentoo''' - Gentoo has its [http://www.gentoo.org/proj/en/qa/backtraces.xml own document] describing how to proceed.
    **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>.  
    *'''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.
    *'''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.  
    ** 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>.
    *'''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].  
    *'''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.)
    *'''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 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 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.
    * 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.  
    Then it's just <tt>make</tt> and <tt>make install</tt> as you're used to.


    === Crash! ===
    ===Crash!===


    Now it's time to crash your application. The KDE Crash Dialog should appear right after the crash, which shows the Backtrace tab.  
    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]]  
    [[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:  
    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".  
      Using host libthread_db library "/lib/libthread_db.so.1".  
    Line 109: Line 112:
         at /home/bram/KDE/kde3/kdeaddons/konq-plugins/fsview/treemap.cpp:720  
         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  
      #8  0xb7281619 in QGList::operator== () from /usr/qt/3/lib/libqt-mt.so.3  
      #9  0x0806d498 in QPtrList&lt;TreeMapItem&gt;::operator== (this=0xbfec04a8,  
      #9  0x0806d498 in QPtrList<TreeMapItem>::operator== (this=0xbfec04a8,  
         list=@0xbfec0468) at /usr/qt/3/include/qptrlist.h:74  
         list=@0xbfec0468) at /usr/qt/3/include/qptrlist.h:74  
      #10 0x08062e18 in TreeMapWidget::mousePressEvent (this=0xbfec03ac,  
      #10 0x08062e18 in TreeMapWidget::mousePressEvent (this=0xbfec03ac,  
    Line 132: Line 135:
         at /home/bram/KDE/kde3/kdeaddons/konq-plugins/fsview/main.cpp:55
         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.  
    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.}}  
    {{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 ===
    ===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.  
    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:  
    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
      $ 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:  
    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
      (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:  
    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.}}  
    {{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
      (gdb) thread apply all backtrace


    This should give a good backtrace which can be posted at the KDE Bugzilla.  
    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:  
    In case you want to attach to an existing process, run the following command in the shell:


      $ gdb someKDEapp pid
      $ 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.  
    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 ===
    ===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 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.  
    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.}}  
    {{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.  
    Like GDB, Valgrind makes running an application much slower, while consuming a lot more resources.


    Start the application within valgrind:  
    Start the application within valgrind:


      $ valgrind --log-file=someKDEapp someKDEapp
      $ 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:  
    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== Invalid read of size 4
      ==23292==    at 0x806BD9E: TreeMapItem::parent() const (treemap.h:285)
      ==23292==    at 0x806BD9E: TreeMapItem::parent() const (treemap.h:285)
      ==23292==    by 0x8065FB9: TreeMapItemList::compareItems(void*, void*) (treemap.cpp:720)
      ==23292==    by 0x8065FB9: TreeMapItemList::compareItems(void*, void*) (treemap.cpp:720)
      ==23292==    by 0x50AC618: QGList::operator==(QGList const&amp;) const (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
      ==23292==    by 0x50AC618: QGList::operator==(QGList const&) const (in /usr/qt/3/lib/libqt-mt.so.3.3.8)
      ==23292==    by 0x806D3BF: QPtrList&lt;TreeMapItem&gt;::operator==(QPtrList&lt;TreeMapItem&gt; const&amp;) const (qptrlist.h:74)
      ==23292==    by 0x806D3BF: QPtrList<TreeMapItem>::operator==(QPtrList<TreeMapItem> const&) const (qptrlist.h:74)
      ==23292==    by 0x8062DE7: TreeMapWidget::mousePressEvent(QMouseEvent*) (treemap.cpp:1840)
      ==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 0x4E2FA62: QWidget::event(QEvent*) (in /usr/qt/3/lib/libqt-mt.so.3.3.8)

    Revision as of 15:32, 1 May 2010


    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 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 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: 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 ?? indicates that the library libkmailprivate.so.4 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 kdepim 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 -dbg packages to easy create useful backtraces. Just install the corresponding -dbg package. e.g. kdepim-dbg 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 KDE on FreeBSD FAQ.
    • Gentoo - Gentoo has its 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 -debug package, like kdebase-debug and kdemultimedia-debug. You probably want to install kdelibs-debug anyways.
      • Note: the -debug packages are in separate repositories. For instance, for all packages in main, you'll find the debugging package in repository debug_main.
    • Kubuntu/Ubuntu - The Ubuntu family makes things quite easy. Every official KDE module has an additional package in the repository, suffixed with -dbg. Always install kdelibs5-dbg, 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 kdepim-dbg 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 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 -debuginfo packages, for example: kdepimlibs4-debuginfo. You can find these packages in KDE repositories. There is also a dedicated openSUSE debugging page.
    • Fedora - Fedora has its 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 --enable-debug=full 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 -DCMAKE_BUILD_TYPE=debugfull. If you want to specify your own CXXFLAGS, then use -DCMAKE_BUILD_TYPE=None CMAKE_CXX_FLAGS="-O0 -g". You can change the CMAKE_CXX_FLAGS as appropriate for your needs.

    Then it's just make and make install 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.

    KDE Crash Dialog
    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 gdb, the 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 run 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, 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 someKDEapp.pid 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.