为啥php会出现500错误呢？急！

Posted 2023-05-18

如果是你访问别人的网站...是网页错误，可以将ie的高级设置里 显示友好http错误信息 哪个选项去掉

如果是你自己的服务器原因就很多了
1服务器资源超载.
如果你查到某个进程消耗过多资源，可以用kill命令强制关闭这个进程，只需输入该进程的进程号

2.文件权限设置错误
那么后台目录和文件的权限默认应该是755，而图片，文字等html文件应该是644，所以如果在刚刚上传文件后出现500错误，应该主要检查文件权限设置。
可以使用FTP软件选中所有文件，然后批量修改文件权限。

3 .htaccess文件写入错误的代码
在使用某些wordpress SEO插件的时候，插件会改写.htacess文件，如果语法错误的话就有可能造成500错误！
在.htaccess文件中，可能因为添入了一些与源文件冲突的代码。所以为了检测到错误语句，最好的方法是为语句添加注释来逐条验证。因为注释之后，语句就不再起作用。
逐条添加“#”在语句前面，如
DirectoryIndex default.html
AddType application/x-httpd-php5 php
你可以添加#到该命令前，从而实现注释效果：
DirectoryIndex default.html
#AddType application/x-httpd-php5 php
这个方法可以迅速定位错误的命令，如果你找不到错误的段落，可以尝试把所有的命令全部添上注释然后反过来逐条删除#检查错误！
判断出错误语句之后，可以删掉#恢复正常！ 参考技术A PHP页面在浏览器出现500错误的时候，一般是PHP教程程序有错造成，可以查看WEB服务器日志获得错误原因和出错的语句行，具体方法与WEB服务器类型和配置相关。获取详细错误信息一般推荐下面两种方法：
一是修改php.ini设置记录错误信息到日志，例如error_log = php_errors.log
二是在控制台运行PHP脚本，系统会显示错误

为啥 PHP 中的无限递归函数会导致段错误？

【中文标题】为啥 PHP 中的无限递归函数会导致段错误？

【英文标题】：Why does an infinitely recursive function in PHP cause a segfault?为什么 PHP 中的无限递归函数会导致段错误？

【发布时间】：2011-11-11 17:55:12

【问题描述】：

一个假设性的问题供大家思考......

我最近回答了关于 SO 的另一个问题，其中 PHP 脚本出现了段错误，这让我想起了我一直想知道的事情，所以让我们看看是否有人能对此有所了解。

考虑以下几点：

<?php

  function segfault ($i = 1) 
    echo "$i\n";
    segfault($i + 1);
  

  segfault();

?>

显然，这个（无用的）函数无限循环。最终，将耗尽内存，因为对函数的每次调用都会在前一次调用完成之前执行。有点像没有分叉的分叉炸弹。

但是...最终，在 POSIX 平台上，脚本会随着 SIGSEGV 而死（它也会在 Windows 上死掉，但更优雅 - 就我极其有限的低级调试技能而言）。循环的数量取决于系统配置（分配给 PHP、32 位/64 位等的内存）和操作系统，但我真正的问题是 - 为什么会发生段错误？

这仅仅是 PHP 处理“内存不足”错误的方式吗？肯定有更优雅的方式来处理这个问题吗？ 这是 Zend 引擎中的错误吗？ 有什么方法可以在 PHP 脚本中更优雅地控制或处理这种情况？ 是否有任何设置通常控制函数中可以进行的最大递归调用数？

【问题讨论】：

According to PHP，这是预期行为。

@NullUserException 这很有趣，我确实搜索了 PHP 错误，但没有发现......他们说它是 known recursion limit 似乎很奇怪，但没有说明限制该限制，或提供任何方式来控制它。正如那个 bug 的报告者所说，如果你编写有 bug 的代码，这只会导致问题，但如果知道边界在哪里就好了。

我希望所有被炸毁的函数都将自己重命名为 segfault - 这肯定会在办公室节省一些漫长的夜晚！

@Lawrence Cherone 在某些情况下，代码不打算用完堆栈但确实（比如说一个完美的递归算法，它遇到了一个退化的情况；你知道一个正常的“漏洞”）。 PHP 只是有一个不可接受的“解决方案”，IMOHO。 （Ruby、Perl 和 Python —— 3 个动态竞争者施加了更理智但有些武断的限制。）

@Lawrence 将段错误称为“非常好的错误代码”有点过分，嗯？

【参考方案1】：

如果您使用 XDebug，则有一个最大函数嵌套深度，由 ini setting 控制：

$foo = function() use (&$foo)  
    $foo();
;
$foo();

产生以下错误：

致命错误：达到“100”的最大函数嵌套级别，正在中止！

这个恕我直言是一个比段错误更好的选择，因为它只杀死当前脚本，而不是整个过程。

几年前（2006 年）内部列表中有this thread。他的 cmets 是：

到目前为止，没有人提出解决无限循环问题的方法 将满足这些条件：

没有误报（即好的代码总是有效的） 执行速度不会减慢 适用于任何堆栈大小

因此，这个问题仍未解决。

现在，由于halting problem，#1 几乎不可能解决。如果您保留堆栈深度计数器，＃2 是微不足道的（因为您只是检查堆栈推送时增加的堆栈级别）。

最后，#3 是一个更难解决的问题。考虑到某些操作系统会以非连续方式分配堆栈空间，因此不可能以 100% 的准确度实现，因为不可能便携地获取堆栈大小或使用情况（对于特定平台，它可能是可能的或甚至很容易，但不是一般的）。

相反，PHP 应该从 XDebug 和其他语言（Python 等）中获取提示，并制作可配置的嵌套级别（Python 默认为 set to1000）....

要么这样，要么在堆栈上捕获内存分配错误以在段错误发生之前检查它并将其转换为RecursionLimitException，以便您可以恢复......

【讨论】：

捕获 SIGSEGV 并抛出异常？

为什么我之前在寻找分段错误的原因时没有找到这个帖子。我花了几个小时在登台服务器上调试这个问题。

【参考方案2】：

我可能完全错了，因为我的测试相当简短。似乎 Php 只有在内存不足时才会出现段错误（并且可能会尝试访问无效地址）。如果设置了内存限制并且足够低，您将事先收到内存不足错误。否则，代码段出错并由操作系统处理。

不能说这是否是一个错误，但可能不应该让脚本像这样失控。

请参阅下面的脚本。无论选项如何，行为实际上都是相同的。如果没有内存限制，它还会在我的计算机被杀死之前严重降低它的速度。

<?php
$opts = getopt('ilrv');
$type = null;
//iterative
if (isset($opts['i'])) 
   $type = 'i';

//recursive
else if (isset($opts['r'])) 
   $type = 'r';

if (isset($opts['i']) && isset($opts['r'])) 


if (isset($opts['l'])) 
   ini_set('memory_limit', '64M');


define('VERBOSE', isset($opts['v']));

function print_memory_usage() 
   if (VERBOSE) 
      echo memory_get_usage() . "\n";
   


switch ($type) 
   case 'r':
      function segf() 
         print_memory_usage();
         segf();
      
      segf();
   break;
   case 'i':
      $a = array();
      for ($x = 0; $x >= 0; $x++) 
         print_memory_usage();
         $a[] = $x;
      
   break;
   default:
      die("Usage: " . __FILE__ . " <-i-or--r> [-l]\n");
   break;

?>

【讨论】：

那里做了一些很好的实验，很好地说明了问题和结果。今天早上进一步谷歌搜索后，我发现this（谷歌缓存，因为该站点已关闭）这表明您可以捕获和处理段错误 - 虽然a）我怀疑它在我们正在处理的内存不足的情况下会起作用和 b) 我没有安装 PCNTL 扩展的机器来测试它。

【参考方案3】：

对 PHP 实现一无所知，但在语言运行时将未分配的页面留在堆栈的“顶部”并不少见，这样如果堆栈溢出就会发生段错误。通常这是在运行时内部处理的，要么扩展堆栈，要么报告更优雅的错误，但可能存在仅允许段错误上升（或逃逸）的实现（和其他情况）。

【讨论】：

我有点理解这背后的原因，但它确实使 PHP 脚本更难调试 - 我不知道段错误是由我的脚本还是 Zend 引擎引起的。收到一条有意义的错误消息会很好，但我接受实际上对此无能为力。

我同意我通常不关心让这类例外情况浮出水面。但我也理解可能会导致这种选择的情况——堆栈溢出是语言运行时中最难处理的事情之一。