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

    From KDE TechBase
    No edit summary
    No edit summary
    Line 72: Line 72:
    這裡有一份發行版如何獲得除錯套件的列表:  
    這裡有一份發行版如何獲得除錯套件的列表:  


    *'''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).
    *'''Debian''' - Debian 提供的 <tt>-dbg</tt> 套件可以更容易建立有用回溯。只要安裝對應的 <tt>-dbg</tt> 套件。例如 <tt>kdepim-dbg</tt> 用於 KMail 當機。-dbg 的相依性可以確保加入其他正確的套件(kdelibs-dbg、gdb,等)。
    <!--*'''Fedora''' ???-->
    *'''FreeBSD ports''' - 請參閱 [http://freebsd.kde.org/faq.php#AKDEapplicationcrashedandIwanttofileabugreportathttpbugskdeorgbutthebacktraceintheKDECrashManagerisuselessWhatcanIdo KDE on FreeBSD FAQ]
    *'''FreeBSD ports''' - Please refer to the [http://freebsd.kde.org/faq.php#AKDEapplicationcrashedandIwanttofileabugreportathttpbugskdeorgbutthebacktraceintheKDECrashManagerisuselessWhatcanIdo KDE on FreeBSD FAQ].
    *'''Gentoo''' - Gentoo [http://www.gentoo.org/proj/en/qa/backtraces.xml 自己的文件],說明如何進行。
    *'''Gentoo''' - Gentoo has its [http://www.gentoo.org/proj/en/qa/backtraces.xml own document] describing how to proceed.
    *'''Mandriva''' - Mandriva 2007.0 和之後的版本,KDE 全部都有額外的除錯套件(實際上,所有的套件都有)。只要安裝對應的 <tt>-debug</tt> 套件,像 <tt>kdebase-debug</tt> <tt>kdemultimedia-debug</tt> 。不管怎樣,你可能想安裝 <tt>kdelibs-debug</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.
    ** 注:<tt>-debug</tt>套件在不同的倉庫。例如,在 <tt>main</tt> 中所有的套件 ,你會發現除錯套件在 <tt>debug_main</tt> 倉庫。
    ** 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.   
    *'''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
    *: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.
    *: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].
    *'''openSUSE''' - 你只需要安裝 <tt>-debuginfo</tt> 套件,例如:<tt>kdepimlibs4-debuginfo</tt>。您可以在[http://en.opensuse.org/KDE/Repositories KDE 套件庫]找到這些套件。此外還有一個專門的[http://en.opensuse.org/Bugs:An_application_crashed openSUSE 除錯頁面]
    *'''Fedora''' - Fedora has its [http://fedoraproject.org/wiki/StackTraces own document] describing how to proceed. (A debuginfo repository has to be enabled.)
    *'''Fedora''' - Fedora [http://fedoraproject.org/wiki/StackTraces 自己的文件],說明如何進行。(必須啟用 debuginfo 套件庫。)


    If your distribution doesn't have debugging-enabled packages for KDE, you'll have to compile KDE from sources:
    如果你的發行版沒有除錯功能的 KDE 套件,你必須從原始碼編譯 KDE:


    * 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.
    * 如果你使用 KDE 4,在 CMake 階段,你應該使用 <tt>-DCMAKE_BUILD_TYPE=debugfull</tt> 參數。如果你想指定自己的 CXXFLAGS,請使用<tt>-DCMAKE_BUILD_TYPE=None CMAKE_CXX_FLAGS="-O0 -g"</tt> 。您可以根據您的需要更改 CMAKE_CXX_FLAGS。
    * 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.
    接者只是 <tt>make</tt> <tt>make install</tt>,就像你所熟悉的。


    ===當機!===
    ===當機!===
    Line 132: Line 130:
         at /home/bram/KDE/kde3/kdeaddons/konq-plugins/fsview/main.cpp:55
         at /home/bram/KDE/kde3/kdeaddons/konq-plugins/fsview/main.cpp:55


    這樣看起來好多了,對不對? 它顯示記憶體地址、原始碼檔案和行號和傳遞給函式的參數。這樣更有助於開發人員找到問題。
    這樣看起來好多了,對不對?它顯示記憶體地址、原始碼檔案和行號和傳遞給函式的參數。這樣更有助於開發人員找到問題。


    {{note_(zh_TW)|您'''需要'''安裝GDB 來獲得當機的回溯。請閱讀下一節了解 GDB,以及如何安裝它。}}
    {{note_(zh_TW)|您'''需要'''安裝GDB 來獲得當機的回溯。請閱讀下一節了解 GDB,以及如何安裝它。}}
    Line 138: Line 136:
    ===使用 GDB 檢索回溯===
    ===使用 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.
    在某些情況下,不可能建立一個 KDE 當機對話框的回溯。這可能是由於應用程式,進入了無限循環,或當機對話框因為某種原因並沒有出現。您可以嘗試使用<tt>gdb</tt>[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:

    Revision as of 07:32, 19 December 2009


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

    簡介

    本文說明如何重現有用的 KDE 應用程式當機(crash)的回溯(backtrace)。首先,提供一些基本資訊。然後,我們將說明在幾個發行版中如何準備您的 KDE 套件,以獲得回溯。這對大多數人就已足夠。其他部分是關於如何用 GNU 除錯器和 Valgrind 建立回溯,這在某些情況下非常有用。

    如何建立有用的當機回報

    一份良好的 Bugzilla 當機回報由兩部分組成:如何重現當機的描述和當機的回溯。如果缺少其中一個要素,開發人員會很難(但不是不可能)解決問題。

    說明不要只有「它當掉了」(it crashed)。嘗試描述當機之前的一切情況。按下一個按鈕、打開一個特定的網站或檔案,才發生問題?這些小細節可能看起來沒有什麼用,但對開發者來說可能是有用的,所以請把它寫下來。

    A more insightful article on how to write good bug descriptions is available at this link, please read that before reporting bugs.

    不要把回溯放在錯誤(bug)回報的附件。相反地,簡單地貼上回報。這種方式開發者更容易尋找重複的回報,因為附件不會被搜尋到。

    如果您貼上回溯到回報,請確定一定從回溯刪除所有

    (no debugging symbols found)
    

    ,不要只有一行或兩行,因為會增加閱讀上的困難。

    即使是直接貼上回溯優於增加一個附件,但請不要貼上其他東西,如日誌(Valgrind、strace或終端輸出)或範例資料(郵件、HTML檔案等)。這些項目請使用附件。

    回溯

    回溯是不可缺少的。他們對你來說可能看起來毫無意義,但實際上它們含有豐富的有用資訊。回溯說明當機之前呼叫哪些函式,使開發者可以追蹤哪個函式開始出問題。擁有良好的回溯有一個缺點:函式庫和可執行檔佔用更多的硬盤空間比其優化的部分。這就是為什麼許多發行版選擇安裝時拿掉檔案,結果造成無用的回溯

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

    但不用擔心,經過一些修改,您可以建立完整成熟的 KDE 應用程式回溯。

    準備你的KDE套件

    如果你的發行版有除錯功能的套件,請安裝它們。

    查看回溯很容易發現你缺少哪些除錯套件。例如,下一行就是來自回溯:

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

    ?? 表示 libkmailprivate.so.4 函式庫沒有除錯資訊,它可能是放在單獨的除錯套件。在這種情況下很容易猜測,您需要安裝 KMail 的除錯套件以得到更好的回溯。

    有時候,你需要安裝一個以上的除錯套件,才能獲得良好的回溯。這取決於發行版如何劃分套件。例如說,一些發行版安裝 kdepim 除錯套件,就可以得到足夠的 KMail 當機的除錯資訊,其他發行版可能還要額外的 KMail 除錯套件。

    這裡有一份發行版如何獲得除錯套件的列表:

    • Debian - Debian 提供的 -dbg 套件可以更容易建立有用回溯。只要安裝對應的 -dbg 套件。例如 kdepim-dbg 用於 KMail 當機。-dbg 的相依性可以確保加入其他正確的套件(kdelibs-dbg、gdb,等)。
    • FreeBSD ports - 請參閱 KDE on FreeBSD FAQ
    • Gentoo - Gentoo 有自己的文件,說明如何進行。
    • Mandriva - Mandriva 2007.0 和之後的版本,KDE 全部都有額外的除錯套件(實際上,所有的套件都有)。只要安裝對應的 -debug 套件,像 kdebase-debugkdemultimedia-debug 。不管怎樣,你可能想安裝 kdelibs-debug
      • 注:-debug套件在不同的倉庫。例如,在 main 中所有的套件 ,你會發現除錯套件在 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 - 你只需要安裝 -debuginfo 套件,例如:kdepimlibs4-debuginfo。您可以在KDE 套件庫找到這些套件。此外還有一個專門的openSUSE 除錯頁面
    • Fedora - Fedora 有自己的文件,說明如何進行。(必須啟用 debuginfo 套件庫。)

    如果你的發行版沒有除錯功能的 KDE 套件,你必須從原始碼編譯 KDE:

    • 如果你使用 KDE 4,在 CMake 階段,你應該使用 -DCMAKE_BUILD_TYPE=debugfull 參數。如果你想指定自己的 CXXFLAGS,請使用-DCMAKE_BUILD_TYPE=None CMAKE_CXX_FLAGS="-O0 -g" 。您可以根據您的需要更改 CMAKE_CXX_FLAGS。

    接者只是 makemake install,就像你所熟悉的。

    當機!

    當你的應用程式當機的時候。KDE 當機對話框應該會在當機後出現,它會顯示回溯分頁。

    KDE 當機對話框
    KDE 當機對話框

    按一下該分頁,並稍等一下。過程可能需要相當記憶體,因此可能會突然變慢。但結束後應該會改善。例如:

    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
    

    這樣看起來好多了,對不對?它顯示記憶體地址、原始碼檔案和行號和傳遞給函式的參數。這樣更有助於開發人員找到問題。

    Template:Note (zh TW)

    使用 GDB 檢索回溯

    在某些情況下,不可能建立一個 KDE 當機對話框的回溯。這可能是由於應用程式,進入了無限循環,或當機對話框因為某種原因並沒有出現。您可以嘗試使用gdbGNU 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:

    Template:Note (zh TW)

    (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.

    使用 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.

    Template:Note (zh TW)

    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.