資訊專欄INFORMATION COLUMN
摘要：使用注冊一個終止時的回調函數(shù)，再調用如果獲取到了最后發(fā)生的錯誤，就通過獲取程序的堆棧信息，我們試試看?？偨Y對于其中使用到的函數(shù)需要注意，可以注冊多個不同的回調，但是如果某一個回調函數(shù)中了，那么后面注冊的回調函數(shù)都不會執(zhí)行。
背景說明
來說說當PHP出現(xiàn)E_ERROR級別致命的運行時錯誤的問題定位方法。例如像Fatal error: Allowed memory size of內存溢出這種。當出現(xiàn)這種錯誤時會導致程序直接退出，PHP的error log中會記錄一條錯誤日志說明報錯的具體文件和代碼行數(shù)，其它的任何信息都沒有了。如果是PHP7的話還可以像捕獲異常一樣捕獲錯誤，PHP5的話就不行了。
一般想到的方法就是看看報錯的具體代碼，如果報錯文件是CommonReturn.class.php像下面這個樣子。
其中json_encode那一行報錯了，然后你查了下packData這個方法，有很多項目的類中都有調用，這時要怎么定位問題呢？
場景復現(xiàn)好，首先我們復現(xiàn)下場景。假如實際調用的程序bug.php如下
運行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復現(xiàn)成功，錯誤日志中只是說明了報錯的文件和哪行代碼，無法知道程序的上下文堆棧信息，不知道具體是哪塊業(yè)務邏輯調用的，這樣一來就無法定位修復錯誤。如果是偶爾出現(xiàn)，并且沒有來自前端業(yè)務的反饋要怎么排查呢。
解決思路有人想到了修改memory_limit增加內存分配，但這種方法治標不治本。做開發(fā)肯定要找到問題的根源。
開啟core dump，如果生成code文件可以進行調試，但是發(fā)現(xiàn)code只有進程異常退出才會生成。像E_ERROR級別的錯誤不一定會生成code文件，內存溢出這種可能PHP內部自己就處理了。
使用register_shutdown_function注冊一個PHP終止時的回調函數(shù)，再調用error_get_last如果獲取到了最后發(fā)生的錯誤，就通過debug_print_backtrace獲取程序的堆棧信息，我們試試看。
修改CommonReturn.class.php文件如下
再次運行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信息保存在內存中，當出現(xiàn)致命錯誤時會清空。沒辦法，把backtrace從外面?zhèn)鬟M來試試。再次修改CommonReturn.class.php。
再次運行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發(fā)布到生產(chǎn)環(huán)境，再次出現(xiàn)出現(xiàn)錯誤時候看日志就可以了。但是這樣的話所有調用packData的程序都會執(zhí)行trace函數(shù)，肯定也會影響性能的。
總結對于其中使用到的register_shutdown_function函數(shù)需要注意，可以注冊多個不同的回調，但是如果某一個回調函數(shù)中exit了，那么后面注冊的回調函數(shù)都不會執(zhí)行。
debug_print_backtrace這個獲取回溯信息函數(shù)第一個是否包含請求參數(shù)，第二個是回溯記錄層數(shù)，我們這里是不返回請求參數(shù)，可以節(jié)省些內存，而且如果請求參數(shù)巨大的話調這個函數(shù)可能就直接內存溢出了。
最好的辦法就是升級PHP7，可以像異常一樣捕獲錯誤。
文章版權歸作者所有，未經(jīng)允許請勿轉載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉載請注明本文地址：http://systransis.cn/yun/29904.html
摘要：是否啟用安全模式。提示此參數(shù)已經(jīng)沒有了關閉危險函數(shù)如果打開了安全模式，那么函數(shù)禁止是不需要的，但是我們?yōu)榱税踩紤]還是設置。 1、PHP引擎緩存加速常見四種軟件：1.eAccelerator2.Zendcache3.xcache4.apc5.zendopcache php5.5自帶2、使用tmpfs作為緩存加速緩存的文件目錄[root@web02 ~]# mount -t tmpfs ...
摘要：是否啟用安全模式。提示此參數(shù)已經(jīng)沒有了關閉危險函數(shù)如果打開了安全模式，那么函數(shù)禁止是不需要的，但是我們?yōu)榱税踩紤]還是設置。 1、PHP引擎緩存加速常見四種軟件：1.eAccelerator2.Zendcache3.xcache4.apc5.zendopcache php5.5自帶2、使用tmpfs作為緩存加速緩存的文件目錄[root@web02 ~]# mount -t tmpfs ...
摘要：是否啟用安全模式。提示此參數(shù)已經(jīng)沒有了關閉危險函數(shù)如果打開了安全模式，那么函數(shù)禁止是不需要的，但是我們?yōu)榱税踩紤]還是設置。 1、PHP引擎緩存加速常見四種軟件：1.eAccelerator2.Zendcache3.xcache4.apc5.zendopcache php5.5自帶2、使用tmpfs作為緩存加速緩存的文件目錄[root@web02 ~]# mount -t tmpfs ...
摘要：安裝在下很多功能都在這個軟件包中了，不在區(qū)分等軟件包了，因此我們可以直接安裝注意這邊的是為了方便安裝，加上它就不需要在進行安裝確認，簡單粗暴一鍵完成安裝的模塊在中的模塊有兩個軟件包，分別是和大多數(shù)情況下應該使用第一個。 安裝Apache 在Ubunt14.04下很多功能都在apache2這個軟件包中了，不在區(qū)分mpm-work,mpm-prefork,mpm-event等軟件包了，因...
閱讀 924·2023-04-25 18:51
閱讀 1883·2021-09-09 11:39
閱讀 3291·2019-08-30 15:53
閱讀 2105·2019-08-30 13:03
閱讀 1318·2019-08-29 16:17
閱讀 591·2019-08-29 11:33
閱讀 1893·2019-08-26 14:00
閱讀 2132·2019-08-26 13:41
