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错误

回答

相关问题