PHP中的preg_match_all上的Fastcgi 500錯誤

我想設置一些外來的PHP代碼（我不是專家），並且在包含'preg_match_all'的PHP行上出現FastCGI錯誤500。PHP中的preg_match_all上的Fastcgi 500錯誤

當我註釋掉該行時，頁面返回200（但不是它應該如何）。

該代碼解析從數據庫加載的PHP，HTML和JavaScript內容，並正在編寫它們以返回完成的頁面。

現在，通過放置一些error_log條目，我可以確定preg_match_all的行是500的原因。但是，在加載頁面期間和其他場合下，該行多次命中，行不會導致錯誤。

下面是它的樣子完全相同：

preg_match_all ("/(<([\w]+)[^>]*>)((?:.|\n)*)(<\/\\2>)/", 
       $part['data'], $tags, PREG_PATTERN_ORDER|PREG_OFFSET_CAPTURE);

主題字符串是一段文字，看起來像：

<script> ... some javascript functions ... </script>

編輯：這是代碼，並正常運行其他地方，所以這很好可能是一個PHP設置或環境差異。我在FastCGI上使用IIS6上的PHP 5.2.13。

編輯：日誌文件中沒有提及任何內容。至少在那些我檢查：

IIS日誌
事件日誌
PHP登錄

編輯：jab11 has pointed out the problem，但沒有解決辦法尚未：

任何想法或方向都會受到歡迎。

來源

2010-03-29 Bertvan

檢查您的錯誤日誌並在此處報告完整的錯誤消息... – ChristopheD 2010-03-29 12:00:38

$part['data']可能會非常大嗎？我以前在preg_match_all上使用它時，在大於100KB的字符串上使用它時出現500錯誤。

來源

2010-03-29 12:07:13 jab11

這確實很大。但它不會在另一個環境中崩潰，並且具有相同的PHP.INI設置。不同之處在於：IIS6 vs II7，WinSrv2003 vs WinSrv2008。我將不得不再次檢查PHP和FastCgi版本... – Bertvan 2010-03-29 12:09:46

大可能被誇大:)，當保存字符串的文本時，它的大約32kB – Bertvan 2010-03-29 12:11:39

這可能是正確的方向看。該字符串是該批次中最大的，並且具有32206的魔術長度。但是，這仍然無法解決問題...可能有設置或其他方法可以解決此問題嗎？ – Bertvan 2010-03-29 12:27:04

這是一個很好的例子，爲什麼用正則表達式處理HTML是一個壞主意。我敢打賭，由於HTML源字符串包含一些未封閉的標籤，因此正在運行堆棧溢出，使得正則表達式試圖嘗試各種排列，試圖找到結束標記（</\2>）。在32 KB的HTML文件中，很容易將您的正則表達式從手推車中移除。也許這個堆棧在不同的服務器上是不同的大小，所以它可以在一個服務器上運行，但不能在另一個服務器上運行

快速測試：

我施加正則表達式到這個頁的源代碼（在已去除的閉合</html>標記）。在匹配<head>和<body>標籤（成功）之前，RegexBuddy迅速進入緊張狀態大約一分鐘。從<html>調試正則表達式表明，它使用正則表達式引擎970257步驟來發現它不匹配。

來源

2010-03-29 13:24:07

在這個代碼庫中完成事情的方式確實不是靠近最佳實踐甚至是好主意的地方。它大部分是非常糟糕的，不可維護的。正如我在問題中所說的那樣，這是一個我試圖在測試環境中設置的異乎尋常的代碼庫。所以，我沒有選擇讓自己運行這個不正當的PHP網站。我的老闆告訴我必須這樣做，這些事情都會發生。但是，謝謝你的回答，我會去看看現在正在分析的內容:) – Bertvan 2010-03-29 13:48:32

PHP中的preg_match_all上的Fastcgi 500錯誤

回答

相關問題