來說說當PHP出現E_ERROR級別致命的運行時錯誤的問題定位方法。例如像Fatal error: Allowed memory size of內存溢出這種。當出現這種錯誤時會導致程序直接退出，PHP的error log中會記錄一條錯誤日志說明報錯的具體文件和代碼行數，其它的任何信息都沒有了。如果是PHP7的話還可以像捕獲異常一樣捕獲錯誤，PHP5的話就不行了。

一般想到的方法就是看看報錯的具體代碼，如果報錯文件是CommonReturn.html' target='_blank'>class.php像下面這個樣子。

 ?php * 公共返回封裝 * Class CommonReturnclass CommonReturn * 打包函數 * @param $params * @param int $status * @return mixed static public function packData($params, $status = 0) $res[ status ] = $status; $res[ data ] = json_encode($params); return $res;}

其中json_encode那一行報錯了，然后你查了下packData這個方法，有很多項目的類中都有調用，這時要怎么定位問題呢？

場景復現

好，首先我們復現下場景。假如實際調用的程序bug.php如下

 ?phprequire_once ./CommonReturn.class.php $res = ini_set( memory_limit , 1m $res = [];$char = str_repeat( x , 999);for ($i = 0; $i 900 ; $i++) { $res[] = $char;$get_pack = CommonReturn::packData($res);// something else

運行bug.php PHP錯誤日志中會記錄

[08-Jan-2019 11:22:52 Asia/Shanghai] PHP Fatal error: Allowed memory size of 1048576 bytes exhausted (tried to allocate 525177 bytes) in /CommonReturn.class.php on line 20

復現成功，錯誤日志中只是說明了報錯的文件和哪行代碼，無法知道程序的上下文堆棧信息，不知道具體是哪塊業務邏輯調用的，這樣一來就無法定位修復錯誤。如果是偶爾出現，并且沒有來自前端業務的反饋要怎么排查呢。

解決思路

1、有人想到了修改memory_limit增加內存分配，但這種方法治標不治本。做開發肯定要找到問題的根源。

2、開啟core dump，如果生成code文件可以進行調試，但是發現code只有進程異常退出才會生成。像E_ERROR級別的錯誤不一定會生成code文件，內存溢出這種可能PHP內部自己就處理了。

3、使用register_shutdown_function注冊一個PHP終止時的回調函數，再調用error_get_last如果獲取到了最后發生的錯誤，就通過debug_print_backtrace獲取程序的堆棧信息，我們試試看。

修改CommonReturn.class.php文件如下

 ?php * 公共返回封裝 * Class CommonReturnclass CommonReturn * 打包函數 * @param $params * @param int $status * @return mixed static public function packData($params, $status = 0) register_shutdown_function([ CommonReturn , handleFatal  $res[ status ] = $status; $res[ data ] = json_encode($params); return $res; * 錯誤處理 static protected function handleFatal() $err = error_get_last(); if ($err[ type ]) { ob_start(); debug_print_backtrace(DEBUG_BACKTRACE_IGNORE_ARGS, 5); $trace = ob_get_clean(); $log_cont = time=%s . PHP_EOL . error_get_last:%s . PHP_EOL . trace:%s . PHP_EOL; @file_put_contents( /tmp/debug_ . __FUNCTION__ . .log , sprintf($log_cont, date( Y-m-d H:i:s ), var_export($err, 1), $trace), FILE_APPEND);}

再次運行bug.php，日志如下。

error_get_last:array ( type = 1, message = Allowed memory size of 1048576 bytes exhausted (tried to allocate 525177 bytes) , file = /CommonReturn.class.php , line = 23,trace:#0 CommonReturn::handleFatal()

回溯信息沒有來源，尷尬了。猜測因為backtrace信息保存在內存中，當出現致命錯誤時會清空。沒辦法，把backtrace從外面傳進來試試。再次修改CommonReturn.class.php。

 ?php * 公共返回封裝 * Class CommonReturnclass CommonReturn * 打包函數 * @param $params * @param int $status * @return mixed static public function packData($params, $status = 0) ob_start(); debug_print_backtrace(DEBUG_BACKTRACE_IGNORE_ARGS, 5); $trace = ob_get_clean(); register_shutdown_function([ CommonReturn , handleFatal ], $trace); $res[ status ] = $status; $res[ data ] = json_encode($params); return $res; * 錯誤處理 * @param $trace static protected function handleFatal($trace) $err = error_get_last(); if ($err[ type ]) { $log_cont = time=%s . PHP_EOL . error_get_last:%s . PHP_EOL . trace:%s . PHP_EOL; @file_put_contents( /tmp/debug_ . __FUNCTION__ . .log , sprintf($log_cont, date( Y-m-d H:i:s ), var_export($err, 1), $trace), FILE_APPEND);}

再次運行bug.php，日志如下。

error_get_last:array ( type = 1, message = Allowed memory size of 1048576 bytes exhausted (tried to allocate 525177 bytes) , file = /CommonReturn.class.php , line = 26,trace:#0 CommonReturn::packData() called at [/bug.php:13]

成功定位到了調用來源，在bug.php的13行。將最終的CommonReturn.class.php發布到生產環境，再次出現出現錯誤時候看日志就可以了。但是這樣的話所有調用packData的程序都會執行trace函數，肯定也會影響性能的。

總結

對于其中使用到的register_shutdown_function函數需要注意，可以注冊多個不同的回調，但是如果某一個回調函數中exit了，那么后面注冊的回調函數都不會執行。

debug_print_backtrace這個獲取回溯信息函數第一個是否包含請求參數，第二個是回溯記錄層數，我們這里是不返回請求參數，可以節省些內存，而且如果請求參數巨大的話調這個函數可能就直接內存溢出了。

最好的辦法就是升級PHP7，可以像異常一樣捕獲錯誤。

以上就是PHP5下的Error錯誤處理及問題定位的介紹（代碼示例）的詳細內容，PHP教程

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。