Xfce Wiki

Sub domains
 

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
howto:debug [2013/04/21 06:38] – haobughowto:debug [2013/04/21 06:40] (current) – sorry for mess it up. haobug
Line 1: Line 1:
-====== 调试 Xfce ======+====== Debugging Xfce ======
  
-当然，我们都知道 Xfce 是无故障且稳如磐石。所以这份 HOWTO 没啥存在的理由。+Ofcourse, we all know Xfce is bugfree and stable as a rock. So there shouldn't be any reason for this howto to exist.
  
-可是，一些（yet）未知的原因，会引起应用程序崩溃。我们不确定这些神奇事件的源头。有些人亲眼目睹 Rodents 的存在，这中间可能有些联系，但不确切。+However, due to some (yet) unexplained cause, it can happen that an application crashes. We are not sure of the origin of these mysterious events. Some people have witnessed the presence of Rodents, maybe there is a relationship, but no-one knows for sure.
  
-不管怎样，如果有神秘事件发生，这是一种可以帮助开发都解决问题的手段：+However, if these mysterious events happen, this is the way you can help the developers resolve it:
  
-===== 确认崩溃 ===== +===== Identifying a crash ===== 
-当应用程序崩溃时，它通常会由于 SIG_SEGV 信号，或段错误退出。这意味着该操作系统检测到应用程序试图访问不允许访问的内存块（段）。操作系统向应用程序发送信号，从而引起应用程序立即中止。+When an application crashed, it usually exits due to SIG_SEGV, a segmentation-fault. This means the operating-system has detected that the application tries to access a piece (segment) of memory that it is not allowed to. The operating-system then sends the application a signal causing an immediate abort.
  
-如果应用程序从终端启动，输出可能像下面这样：+When the application is started from a terminal, this can look like the following example:
 <code> <code>
 stephan@hermes:~$ ristretto stephan@hermes:~$ ristretto
-段错误+Segmentation fault
 stephan@hermes:~$ stephan@hermes:~$
 </code> </code>
  
-这条消息只是简短的描述，让我们尝试找出它崩溃的原因。+This message is little descriptive, so lets try to find out why it crashed.
  
-===== 在调试器中运行程序 ===== +===== Running the application in a debugger ===== 
-要找出应用程序为什么崩溃，首先要在调试器中运行它。 GNU/Linux 上最常用的调试器是 gdb（GNU 调试器）。+To find out why the application crashed, the first thing to try is running it in a debugger. The most commonly used debugger on GNU/Linux is gdb, the GNU debugger.
  
-使用 gdb ，你只用从命令行里启动它，把要调试应用程序作为它第一个参数，看下面的例子：+To use gdb, you just start it from the command-line with the application to debug as a first argument to the application, see the following example:
 <code> <code>
 stephan@hermes:~$ gdb ristretto  stephan@hermes:~$ gdb ristretto 
Line 38: Line 38:
 </code> </code>
  
-现在 gdb 是启动了，但应用程序还没有做任何事情。 +Now gdb is started, but the application itself is not doing anything yet. 
-要启动的应用程序，键入 ''run''，一些你可能想给应用程序的参数，然后 ''Enter''。+To start the application, type ''run'', maybe some arguments you want to supply to the application, and press ''Enter''. 
 + 
 +Now, if the application does not crash immediately, you should see it start and a few lines appear in the debugger. (See the following example)
  
-现在，如果应用程序没有立即崩溃，你可以看到它启动了并且调试器里出现几行字。（见下面的例子） 
 <code> <code>
 ... ...
Line 49: Line 50:
 </code> </code>
  
-现在，执行让应用程序崩溃所需的动作。下一步的调试器看起来像这样：+Now, perform the actions required to crash the application. The next step of the debugger looks something like this: 
 <code> <code>
 (gdb) run (gdb) run
Line 64: Line 66:
 </code> </code>
  
-当然，应用程序的不同，或 bug 的不同会有不同的输出，所以如果输出不一样不用担心。+Ofcourse, the output-lines differ from application to application and from bug to bug, so you shouldn't be worried if it looks different. 
 + 
 +The next step is getting a so called 'backtrace'. This backtrace traces the flow through the application that leads to this crash:
  
-下一步是得到一个所谓的“回溯”（backtrace）。回溯可以追踪到导致应用程序崩溃的流程： 
 <code> <code>
 (gdb) backtrace (gdb) backtrace
Line 161: Line 164:
 (gdb) (gdb)
 </code> </code>
-将它复制到一个文本文件中，并把它添加到 https://bugzilla.xfce.org/ 的 bug 报告。 
  
-但如果回溯的最后一行以 0x000000000000（空指针）开始， then the backtrace is not of any good。应用程序跳转到一个空指针，然后在内存里瞎跑一阵最后死掉。如果是这种情况，请尝试使用 valgrind 。 --（未完待续）+Copy this to a text-file, and add it to a bugreport on https://bugzilla.xfce.org/ 
 + 
 +If the last line of the backtrace starts with 0x000000000000 (a NULL-pointer) then the backtrace is not of any good. The application jumped to a NULL-pointer and then wandered through memory aimlessly before finally dying. If this happens, try valgrind. -- (to be continued)