Xdebug的安裝-（無錯可執行版）

 

xdebug是一個開源的php調試器，以php模組的形式載入並被使用。可以用來跟蹤，調試和分析PHP程式的健全狀態.

這裡以PHP5.2.13為例,

1.下載php_xdebug-2.1.0-5.2.dll檔案,

http://www.xdebug.org/download.php

選擇：PHP 5.2 VC6 TS (32 bit)

選擇VC6還是VC9?

標明 MSVC9 (Visual C++ 2008) 的是VC9
如果你在apache1或者apache2下使用PHP，你應該選擇VC6的版本
如果你在IIS下使用PHP應該選擇VC9的版本
VC6的版本使用visual studio6編譯
VC9使用Visual Studio 2008編譯，並且改進了效能和穩定性。VC9版本的PHP需要你安裝Microsoft 2008 C++ Runtime
不要在apache下使用VC9的版本

2.把檔案重新命名php_xdebug.dll.然後放在php的安裝目錄下的ext目錄下.

3.修改php.ini檔案

在檔案中加入一下代碼

[Xdebug]
zend_extension_ts = "c:/php/ext/php_xdebug-2.1.2-5.2-vc6.dll"

xdebug.collect_params=On
xdebug.collect_return=On
xdebug.trace_output_dir="F:\phpweb\xdebug" //設定函數調用監測資訊的輸出檔案的路徑。
xdebug.profiler_enable=On  //開啟效能監測器。
xdebug.profiler_output_dir="F:\phpweb\xdebug" //設定效能監測資訊輸出檔案的路徑。

 

4.重啟Apache

 

5.測試,建一個test.php

內容為<?php  phpinfo();?>

 

如果輸出的內容中有看到xdebug，說明安裝配置成功。

 

這個時候注釋phpinfo();

寫上如下代碼故意引發異常：

      <?phprequire_once("abc.php");?>

重新重新整理網頁：

然後通過瀏覽器訪問，我們驚奇地發現，出錯資訊變成了彩色的了：

不過除了樣式改變，和我們平時列印的出錯資訊內容沒什麼不同，意義不大。好，我們繼續改寫程式：

<?phptestXdebug();function testXdebug() {       require_once('abc.php');}?>

重新重新整理網頁：

發現了什嗎？　Xdebug跟蹤代碼的執行，找到了出錯的函數testXdebug()。
我們把代碼再寫得複雜一些：

<?phptestXdebug();function testXdebug() {       requireFile();}function requireFile() {       require_once('abc.php');}?>

重新整理網頁：

Xdebug具有類似於Java的Exception的“跟蹤回溯”的功能，可以根據程式的執行一步步跟蹤到出錯的具體位置，哪怕程式中的調用很複雜，我們也可以通過這個功能來理清代碼關係，迅速定位，快速排錯。

擴充閱讀：

Xdebug配置

第一部分：基本特徵:
相關參數設定
xdebug.default_enable
類型：布爾型 預設值：On
如果這項設定為On，堆疊追蹤將被預設的顯示在錯誤事件中。你可以通過在代碼中使用xdebug_disable()來禁止堆疊跟蹤的顯示。因為這是xdebug準系統之一，將這項參數設定為On是比較明智的。
xdebug.max_nesting_level
類型：整型 預設值：100
The value of this setting is the maximum level of nested functions that are allowed before the script will be aborted.
限制無限遞迴的訪問深度。這項參數設定的值是指令碼失敗前所允許的嵌套程式的最大訪問深度。

第二部分：堆疊追蹤:
相關參數設定
xdebug.dump_globals
類型：布爾型 預設值：1
限制是否顯示被xdebug.dump.*設定定義的超全域變數的值
例如，xdebug.dump.SERVER = REQUEST_METHOD,REQUEST_URI,HTTP_USER_AGENT 將列印 PHP 超全域變數 $_SERVER['REQUEST_METHOD']、$_SERVER['REQUEST_URI'] 和 $_SERVER['HTTP_USER_AGENT']。
xdebug.dump_once
類型：布爾型 預設值：1
限制是否超全域變數的值應該轉儲在所有出錯環境(設定為Off時)或僅僅在開始的地方(設定為On時)
xdebug.dump_undefined
類型：布爾型 預設值：0
如果你想從超全域變數中轉儲未定義的值，你應該把這個參數設定成On，否則就設定成Off
xdebug.show_exception_trace
類型：整型 預設值：0
當這個參數被設定為1時，即使捕捉到異常，xdebug仍將強制執行異常跟蹤當一個異常出現時。
xdebug.show_local_vars
類型：整型 預設值：0
當這個參數被設定為不等於0時，xdebug在錯環境中所產生的堆棧轉儲還將顯示所有局部變數，包括尚未初始化的變數在最上面。要注意的是這將產生大量的資訊，也因此預設情況下是關閉的。

第三部分：分析PHP指令碼
相關參數設定
xdebug.profiler_append
類型：整型 預設值：0
當這個參數被設定為1時，檔案將不會被追加當一個新的需求到一個相同的檔案時(依靠xdebug.profiler_output_name的設定)。相反的設定的話，檔案將被附加成一個新檔案。
xdebug.profiler_enable
類型：整型 預設值：0
開放xdebug檔案的許可權，就是在檔案輸出目錄中建立檔案。那些檔案可以通過KCacheGrind來閱讀來展現你的資料。這個設定不能通過在你的指令碼中調用ini_set()來設定。
xdebug.profiler_output_dir
類型：字串 預設值：/tmp
這個檔案是profiler檔案輸出寫入的，確信PHP使用者對這個目錄有寫入的許可權。這個設定不能通過在你的指令碼中調用ini_set()來設定。
xdebug.profiler_output_name
類型：字串 預設值：cachegrind.out%p
這個設定決定了轉儲跟蹤寫入的檔案的名稱。

第四部分：遠程Debug
相關參數設定
xdebug.remote_autostart
類型：布爾型 預設值：0
一般來說，你需要使用明確的HTTP GET/POST變數來開啟遠程debug。而當這個參數設定為On，xdebug將經常試圖去開啟一個遠程debug session並試圖去串連用戶端，即使GET/POST/COOKIE變數不是當前的。
xdebug.remote_enable
類型：布爾型 預設值：0
這個開關控制xdebug是否應該試著去串連一個按照xdebug.remote_host和xdebug.remote_port來設定監聽主機和連接埠的debug用戶端。
xdebug.remote_host
類型：字串 預設值：localhost
選擇debug用戶端正在啟動並執行主機，你不僅可以使用主機名稱還可以使用IP地址
xdebug.remote_port
類型：整型 預設值：9000
這個連接埠是xdebug試著去串連遠程主機的。9000是一般用戶端和被綁定的debug用戶端預設的連接埠。許多用戶端都使用這個連接埠數字，最好不要去修改這個設定。
注意：所有以上參數修改後，要重啟Apache才會生效！

Xdebug調試
其實PHP函數debug_backtrace()也有類似的功能，但是要注意debug_backtrace()函數只在PHP4.3.0之後版本及
PHP5中才生效。這個函數是PHPTeam Dev在PHP5中新增的函數，然後又反向移植到PHP4.3中。
Xdebug使調試資訊更加美觀
Xdebug擴充載入後，Xdebug會對原有的某些PHP函數進行覆寫，以便好更好地進行Debug。比如var_dump()函數，我們知道通常我們 需要在函數前後加上”<pre>…</pre>”才能夠讓輸出的變數資訊比較美觀、可讀性好。但是載入了Xdebug後，我們不 再需要這樣做了，Xdebug不但自動給我們加上了<pre>標籤，還給變數加上顏色。
例：
<?php
$arrTest=array(
       "test"=>"abc",
       "test2"=>"abc2"
);
var_dump($arrTest);
?>
輸出：

看到了嗎？　數組元素的值自動顯示顏色。
如果你還是希望使用PHP的var_dump函數 只要在php.ini關於xdebug的配置中加上 xdebug.overload_var_dump = Off 即可
Xdebug測試指令碼執行時間
測試某段指令碼的執行時間，通常我們都需要用到microtime()函數來確定目前時間。例如PHP手冊上的例子：
<?php
/**
* Simple function to replicate PHP 5 behaviour
*/
function microtime_float()
{
    list($usec, $sec) = explode(" ", microtime());
return ((float)$usec + (float)$sec);
}
$time_start = microtime_float();
// Sleep for a while
usleep(100);
$time_end = microtime_float();
$time = $time_end - $time_start;
echo "Did nothing in $time seconds\n";
?>
但是microtime()返回的值是微秒數及絕對時間戳記（例如“0.03520000 1153122275”），沒有可讀性。所以如上程式，我們需要另外寫一個函數microtime_float()，來將兩者相加。
Xdebug內建了一個函數xdebug_time_index()來顯示時間。

PHP指令碼佔用的記憶體
有時候我們想知道程式執行到某個特定階段時到底佔用了多大記憶體，為此PHP提供了函數memory_get_usage()。這個函數只有當PHP編譯時間使用了--enable-memory-limit參數時才有效。　
Xdebug同樣提供了一個函數xdebug_memory_usage()來實現這樣的功能，另外xdebug還提供了一個xdebug_peak_memory_usage()函數來查看記憶體佔用的峰值。

WinCacheGrind
有時候代碼沒有明顯的編寫錯誤，沒有顯示任何錯誤資訊（如error、warning、notice等），但是這不表明代碼就是正確無誤的。有時候可能某 段代碼執行時間過長，佔用記憶體過多以致於影響整個系統的效率，我們沒有辦法直接看出來是哪部份代碼出了問題。這時候我們希望把代碼的每個階段的運行情況都 監控起來，寫到記錄檔中去，運行一段時間後再進行分析，找到問題所在。
回憶一下，之前我們編輯php.ini檔案
加入
[Xdebug]
xdebug.profiler_enable=on
xdebug.trace_output_dir="I:\Projects\xdebug"
xdebug.profiler_output_dir="I:\Projects\xdebug"
這幾行，目的就在於把執行情況的分析檔案寫入到”I:\Projects\xdebug”目錄中去（你可以替換成任何你想設定的目錄）。如果你執行某段程 序後，再開啟相應的目錄，可以發現產生了一堆檔案，例如cachegrind.out.1169585776這種格式命名的檔案。這些就是Xdebug生 成的分析檔案。用編輯器開啟你可以看到很多程式啟動並執行相關細節資訊，不過很顯然這樣看太累了，我們需要用圖形化的軟體來查看。
WinCacheGrind下載
在Windows平台下，可以用WinCacheGrind(wincachegrind.souceforge.net)這個軟體來開啟這些檔案。可以直觀漂亮地顯示其中內容：

WinCacheGrind小結：
Xdebug提供了各種內建的函數，並對已有的某些PHP函數進行覆寫，可以方便地用於調試排錯；Xdebug還可以跟蹤程式的運行，通過對記錄檔的分析，我們可以迅速找到程式啟動並執行瓶頸所在，提高程式效率，從而提高整個系統的效能。