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

From KDE TechBase
(Continuing translation)
(Continuing translation)
Line 79: Line 79:
*'''Mandriva''' - Mandriva 2007.0+ possède des paquets de débogage supplémentaires pour tous les paquets KDE. Installez simplement le paquet <tt>-debug</tt> correspondant, comme <tt>kdebase-debug</tt> et <tt>kdemultimedia-debug</tt>. Vous devriez d'ailleurs installer le paquet <tt>kdelibs-debug</tt> dans tous les cas.
*'''Mandriva''' - Mandriva 2007.0+ possède des paquets de débogage supplémentaires pour tous les paquets KDE. Installez simplement le paquet <tt>-debug</tt> correspondant, comme <tt>kdebase-debug</tt> et <tt>kdemultimedia-debug</tt>. Vous devriez d'ailleurs installer le paquet <tt>kdelibs-debug</tt> dans tous les cas.
** Note : les paquets <tt>-debug</tt> sont dans des dépôts différents. Par exemple, pour tous les paquets <tt>main</tt>, vous trouverez les paquets de débogage dans le dépôt <tt>debug_main</tt>.
** Note : les paquets <tt>-debug</tt> sont dans des dépôts différents. Par exemple, pour tous les paquets <tt>main</tt>, vous trouverez les paquets de débogage dans le dépôt <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.
*'''Kubuntu/Ubuntu''' - La famille Ubuntu facilite les choses. Un paquet supplémentaire est disponible pour chaque module officiel de KDE dans les dépôts, ayant un suffixe <tt>-dbg</tt>. Vous devez obligatoirement installer <tt>kdelibs5-dbg</tt> car toutes les applications KDE utilisent kdelibs (kdelibs-dbg pour les applications KDE 3). Vous devriez alors installer le paquet -dbg pour l'application qui a planté. Par exemple, si KOrganizer a planté, vous devriez installer <tt>kdepim-dbg</tt>. Si le programme n'est pas un module KDE officiel, et n'a pas de paquet -dbg associé, vous pouvez installer le paquet -dbgsym à partir du dépôt décrit dans cette [https://wiki.kubuntu.org/DebuggingProgramCrash 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
*Pendant le cycle de développement d'Ubuntu, le gestionnaire de plantage Apport est activé et soumettra les plantages et les backtraces pour vous ; si vous préférez utiliser le gestionnaire de plantage manuel, vous pouvez désactiver Apport dans /etc/defaults/apport
*'''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].
*'''openSUSE''' - Vous ne devriez installer que les paquets <tt>-debuginfo</tt>, par exemple <tt>kdepimlibs4-debuginfo</tt>. Vous pouvez trouver ces paquets dans les [http://en.opensuse.org/KDE/Repositories dépôts KDE]. Il existe aussi une [http://en.opensuse.org/Bugs:An_application_crashed page dédiée au débogage].
*'''Fedora''' - Fedora has its [http://fedoraproject.org/wiki/StackTraces own document] describing how to proceed. (A debuginfo repository has to be enabled.)
*'''Fedora''' - Fedora a son [http://fedoraproject.org/wiki/StackTraces propre document] décrivant la marche à suivre. (Un dépôt debuginfo doit être activé.)


If your distribution doesn't have debugging-enabled packages for KDE, you'll have to compile KDE from sources:
Si votre distibution n'a pas de paquets de débogage pour KDE, vous devrez compiler KDE à partir des 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.
* Si vous utilisez KDE 3, à l'étape configure, vous devrez donner le paramètre <tt>--enable-debug=full</tt> pour obtenir les symboles de débogage.
* 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.
* Si vous utilisez KDE 4, à l'étape cmake, vous devrez donner le paramètre <tt>-DCMAKE_BUILD_TYPE=debugfull</tt>. Si vous souhaitez spécifier vos propres CXXFLAGS, utilisez <tt>-DCMAKE_BUILD_TYPE=None CMAKE_CXX_FLAGS="-O0 -g"</tt>. Vous pouvez changer les CMAKE_CXX_FLAGS comme vous le souhaitez.


Then it's just <tt>make</tt> and <tt>make install</tt> as you're used to.
Ensuite, ce sont les <tt>make</tt> et <tt>make install</tt> habituels.


===Crash!===
===Plantage !===


Now it's time to crash your application. The KDE Crash Dialog should appear right after the crash, which shows the Backtrace tab.
C'est le moment de planter votre application. La fenêtre de plantage KDE devrait apparaître après le plantage, avec son onglet Backtrace.


[[Image:Kde-crash-handler.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:
Cliquez sur cet onglet et attendez un peu. Le processus risque de prendre beaucoup de ressources mémoire, alors tout risque de ralentir d'un coup. Mais le résultat devrait être bien meilleur. Par exemple :


  Using host libthread_db library "/lib/libthread_db.so.1".  
  Using host libthread_db library "/lib/libthread_db.so.1".  
Line 132: Line 132:
     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.
C'est mieux non ? On voit des adresses mémoire, des fichiers sources, des numéros de ligne et les paramètres passés aux fonctions. Ce qui est très utile au développeur pour trouver le problème.


{{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|Vous '''devez''' avoir GDB installé pour obtenir la backtrace d'un plantage. Veuillez lire la section suivante pour savoir ce qu'est GDB et comment l'installer.


===Retrieving a backtrace with GDB===
===Récupérer une backtrace avec 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.
Dans certains cas, il n'est pas possible de créer une backtrace avec la fenêtre de plantage KDE. Cela peut se produire si une application est entrée dans une boucle infinie, ou si la fenêtre de plantage de KDE n'est pas apparue pour quelque raison. Vous pouvez essayer de récupérer une backtrace avec <tt>gdb</tt>, le [http://sourceware.org/gdb/ débogueur GNU]. GDB est disponible dans la plupart des distributions.


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:

Revision as of 01:49, 6 November 2010


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

Introduction

Ce document décrit comment obtenir une "backtrace" utile du plantage des applications KDE. Nous allons commencer par donner quelques informations générales. Ensuite, nous décrirons pour quelques distributions comment préparer vos paquetages KDE pour obtenir la backtrace. Ceci devrait suffire pour la plupart des utilisateurs. Des sections supplémentaires expliquent comment créer des backtraces avec le débogueur GNU et Valgrind, qui sont parfois utiles.

Comment créer des rapports d'erreur utiles

Un bon rapport d'erreur de Bugzilla se compose de deux parties: une description de la façon de reproduire le crash et une backtrace du crash. Si l'un de ces éléments est manquant, il est beaucoup plus difficile (voire impossible) pour les développeurs de s'attaquer au problème.

Une description devrait donner plus d'informations que seulement "ça a buggé". Essayez de décrire tout ce que vous avez fait avant le crash. Avez-vous cliqué sur un bouton, ouvert un site Web particulier ou est-ce l'ouverture d'un fichier qui a causé des problèmes ? Ce petit détail qui peut vous sembler inutile peut être utile pour le développeur, alors il vaut mieux le signaler.

Un article plus précis sur la façon de bien rédiger les descriptions de bogues est disponible ici (en anglais).

Ne mettez pas la backtrace en pièce jointe au rapport de bogue. Copiez/collez-le simplement dedans. De cette manière, il est beaucoup plus facile pour les développeurs de chercher les rapports en double puisque les pièces jointes ne sont pas examinées.

Si vous collez une backtrace dans un rapport de bogue, merci de supprimer toutes les lignes

(no debugging symbols found)

de la backtrace sauf une ou deux car elles rendent le rapport plus difficile à lire.

Même s'il vaut mieux copier/coller les backtraces directement dans le rapport de bogue plutôt que les mettre en pièces jointes, merci de ne pas copier/coller d'autres informations telles que les logs (valgrind, strace ou sortie du terminal) ou des exemples (e-mails, fichiers HTML etc.). Veuillez utiliser les pièces jointes pour ces informations.

Backtraces

Les backtraces sont très importantes. Elles peuvent vous paraître incompréhensibles mais elles contiennent des tonnes d'informations utiles. Une backtrace permet de savoir quelles sont les fonctions qui ont été appelées avant le plantage pour que les développeurs puissent savoir quelle fontion est la cause du problème. Cependant, obtenir de bonnes backtraces présente un inconvénient : les bibliothèques et exécutables requis occupent beaucoup plus d'espace disque que ceux qui sont optimisés. C'est pourquoi beaucoup de distributions choisissent d'installer les versions optimisées, ce qui donne des backtraces inutiles :

(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 ?? ()

Mais pas d'inquiétude, avec quelques modifications, vous pourrez créer des backtraces complètes pour les applications KDE.

Préparer vos paquets KDE

Si votre distribution possède des paquets contenant des informations de débogage, installez-les.

Il est facile de voir quels sont les paquets de débogage qu'il vous manque en regardant la backtrace. Par exemple, regardons la ligne de backtrace suivante :

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

Le ?? indique que la bibliothèque libkmailprivate.so.4 ne possède pas d'informations de débogage, qui peuvent être disponibles dans un paquet de débogage séparé. Dans ce cas, on peut raisonnablement en déduire qu'on obtiendra une mailleure backtrace en installant les paquets de débogage de KMail.

Parfois, il faudra installer plusieurs paquets de débogage pour obtenir une bonne backtrace. Cela dépend de la manière dont la distributions sépare les paquets. Par exemple, pour certaines distributions, il suffit d'installer le paquet de débogage pour kdepim pour obtenir suffisamment d'informations de débogage sur un crash de KMail, alors que pour d'autres, il existe un paquet de débogage pour KMail seul.

Voici une liste détaillant la méthode pour obtenir les paquets de débogage pour quelques distributions :

  • Debian - Debian propose des paquets -dbg qui permettent de créer facilement des backtraces utiles. Il suffit d'installer le paquet -dbg correspondant, par ex. kdepim-dbg pour un crash de KMail. Les dépendances des paquets -dbg assurent que l'on installe bien les paquets associés (kdelibs-dbg, gdb, etc.).
  • FreeBSD ports - Veuillez consulter la FAQ KDE sur FreeBSD (en).
  • Gentoo - Gentoo propose son propre document (en) décrivant la manière de procéder.
  • Mandriva - Mandriva 2007.0+ possède des paquets de débogage supplémentaires pour tous les paquets KDE. Installez simplement le paquet -debug correspondant, comme kdebase-debug et kdemultimedia-debug. Vous devriez d'ailleurs installer le paquet kdelibs-debug dans tous les cas.
    • Note : les paquets -debug sont dans des dépôts différents. Par exemple, pour tous les paquets main, vous trouverez les paquets de débogage dans le dépôt debug_main.
  • Kubuntu/Ubuntu - La famille Ubuntu facilite les choses. Un paquet supplémentaire est disponible pour chaque module officiel de KDE dans les dépôts, ayant un suffixe -dbg. Vous devez obligatoirement installer kdelibs5-dbg car toutes les applications KDE utilisent kdelibs (kdelibs-dbg pour les applications KDE 3). Vous devriez alors installer le paquet -dbg pour l'application qui a planté. Par exemple, si KOrganizer a planté, vous devriez installer kdepim-dbg. Si le programme n'est pas un module KDE officiel, et n'a pas de paquet -dbg associé, vous pouvez installer le paquet -dbgsym à partir du dépôt décrit dans cette page.
  • Pendant le cycle de développement d'Ubuntu, le gestionnaire de plantage Apport est activé et soumettra les plantages et les backtraces pour vous ; si vous préférez utiliser le gestionnaire de plantage manuel, vous pouvez désactiver Apport dans /etc/defaults/apport
  • openSUSE - Vous ne devriez installer que les paquets -debuginfo, par exemple kdepimlibs4-debuginfo. Vous pouvez trouver ces paquets dans les dépôts KDE. Il existe aussi une page dédiée au débogage.
  • Fedora - Fedora a son propre document décrivant la marche à suivre. (Un dépôt debuginfo doit être activé.)

Si votre distibution n'a pas de paquets de débogage pour KDE, vous devrez compiler KDE à partir des sources :

  • Si vous utilisez KDE 3, à l'étape configure, vous devrez donner le paramètre --enable-debug=full pour obtenir les symboles de débogage.
  • Si vous utilisez KDE 4, à l'étape cmake, vous devrez donner le paramètre -DCMAKE_BUILD_TYPE=debugfull. Si vous souhaitez spécifier vos propres CXXFLAGS, utilisez -DCMAKE_BUILD_TYPE=None CMAKE_CXX_FLAGS="-O0 -g". Vous pouvez changer les CMAKE_CXX_FLAGS comme vous le souhaitez.

Ensuite, ce sont les make et make install habituels.

Plantage !

C'est le moment de planter votre application. La fenêtre de plantage KDE devrait apparaître après le plantage, avec son onglet Backtrace.

KDE Crash Dialog
KDE Crash Dialog

Cliquez sur cet onglet et attendez un peu. Le processus risque de prendre beaucoup de ressources mémoire, alors tout risque de ralentir d'un coup. Mais le résultat devrait être bien meilleur. Par exemple :

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

C'est mieux non ? On voit des adresses mémoire, des fichiers sources, des numéros de ligne et les paramètres passés aux fonctions. Ce qui est très utile au développeur pour trouver le problème.

{{note|Vous devez avoir GDB installé pour obtenir la backtrace d'un plantage. Veuillez lire la section suivante pour savoir ce qu'est GDB et comment l'installer.

Récupérer une backtrace avec GDB

Dans certains cas, il n'est pas possible de créer une backtrace avec la fenêtre de plantage KDE. Cela peut se produire si une application est entrée dans une boucle infinie, ou si la fenêtre de plantage de KDE n'est pas apparue pour quelque raison. Vous pouvez essayer de récupérer une backtrace avec gdb, le débogueur GNU. GDB est disponible dans la plupart des distributions.

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.