php - 困惑的: PHP Fatal error: Exception thrown without a stack frame in Unknown on line 0?

Question

我发现该错误的一个常见原因是an exception being thrown from within an exception handler。我非常确定这在我要调试的应用程序中不会发生...但是我已经将所有初始化处理行放在try/catch中的index.php顶部。*

显然也可能发生这种情况，因为some things cannot be serialized to be stored in a session。这个应用程序最多只能将数组存储到 session 中(相当多)，但是我相信它不会在其中存储任何异常内容。

有人评论说这是发生在他们身上的，因为他们的主键needed to be CHAR(32) instead of INT(11)。此应用程序中的PK都是INT。

其他建议是PHP 5.3.3，fixed in 5.3.6和full disk可能是一个问题。我们确实在运行PHP 5.3.3，但是在这种情况下，升级必须是最后的手段。它并非一直都在这样做。

更新/注意:我实际上无法自己重现该错误，只能在日志中看到它的发生，请参阅以下段落以了解我认为该错误正在发生的位置...

*从错误日志来看，似乎正在发生的至少一个地方是index.php。我之所以推断出这一点，仅是因为在某些条目中通过引用URL进行了指示。目前，try/catch代码仅位于脚本的“顶部”初始化部分附近，而该部分下面大部分是HTML输出。输出中有一些PHP代码(虽然很简单)，所以我可能需要测试一下。这是catch部分，它不会在日志中产生任何输出:

} catch (Exception $e) {
    error_log(get_class($e)." thrown. Message: ".$e->getMessage(). "  in " . $e->getFile() . " on line ".$e->getLine());
    error_log('Exception trace stack: ' . print_r($e->getTrace(),1));
}

非常感谢您提供任何提示!

编辑:PHP作为Apache模块(服务器API:Apache 2.0 Handler)运行。我认为没有使用任何PHP加速器，但是可能只是我不知道如何分辨。 need to typecast a SimpleXML value都不在phpinfo()中。

据我所知，MPM是前叉。这是我第一次研究MPM:

# ./httpd -l
Compiled in modules:
  core.c
  prefork.c
  http_core.c
  mod_so.c

Answer 1

问题

简而言之，您会在某个地方抛出异常，您不知道在哪里，直到现在您都无法重现该错误:此错误仅对某些人有效，对您而言不适用。您知道其他人也会发生这种情况，因为您在错误日志中看到了这种情况。

重现问题

由于您已经消除了常见原因，因此需要重现该错误。如果您知道哪个参数将导致错误，则应该很容易找到错误。

如果您知道所有POST/GET参数，则很可能就足够了。

如果您不能仅使用这些文件进行复制，则需要了解其他请求 header 。如用户代理，accept-encoding，...

如果您仍然无法复制，则将变得非常困难:错误可能取决于状态( session )，当前时间，源IP地址等。

自定义日志方法

让我们从简单开始:要获取所有参数，您可以在受影响的php文件的最开始编写类似以下内容的代码:

file_put_contents("/path/to/some/custom_error_log", date()."\n".print_r(get_defined_vars(), true), FILE_APPEND | LOCK_EX);

不要忘记custom_error_log文件必须可写到您的php应用程序。然后，当错误日志中发生错误时，在custom_error_log文件中找到相应的行。希望每秒没有太多请求，以便您仍然可以识别请求。错误日志中的某些其他参数，例如源ip可以帮助您识别请求(如果您的错误日志显示了此信息)。
根据该数据，使用相同的POST/GET参数重建请求。

tcpdump方法

下一个选项也非常简单，但是要求您在目标计算机上具有root用户访问权限是安装tcpflow。然后创建一个文件夹，cd进入该文件夹，然后简单地(以root身份)执行 tcpflow "port 80"。选项(端口80)是pcap过滤器表达式。要查看所有功能，请参阅 man pcap-filter。这些过滤器表达式可以做很多事情。

现在，tcpflow将记录端口80上的所有tcp连接，通过组合属于一个连接的程序包来重建完整的数据交换，并将此数据转储到文件中，为每个连接创建两个新文件，一个用于传入数据，另一个用于传出数据。现在，再次根据错误日志中的时间戳和文件的最后修改时间戳，找到导致错误的连接的文件。然后，您将获得完整的http请求 header 。现在，您可以完全重建HTTP请求，包括设置相同的accept-encoding，user-agent等。您甚至可以将请求直接通过管道传输到netcat中，重播确切的请求。请注意，像sessionid这样的参数可能会妨碍您的工作。如果php发现 session 已过期，则可能会重定向到登录名或其他意外的事件。您可能需要交换 session ID之类的内容。

模拟更多事情

如果以上方法均无济于事，并且您无法在计算机上重现该错误，则可以尝试模拟所有难以模拟的内容。例如源IP地址。这可能需要一些技巧，但是有可能:您可以使用带有“-w”选项的ssh连接到服务器，从而创建隧道接口(interface)。然后将有问题的IP地址分配给您自己的计算机，并设置路由(route add host)规则以将隧道用于特定的IP。如果您可以将两台计算机直接电缆连接在一起，那么您甚至可以在不使用隧道的情况下进行连接。

不要 mock 应该是最简单的 session 。您可以使用带有print_r(get_defined_vars())的方法读取所有 session 变量。然后，您需要创建一个具有完全相同变量的 session 。

询问用户

另一个选择是实际上询问用户他在做什么。也许您可以按照与他相同的步骤进行复制。

如果这些都没有帮助

如果这些都没有帮助...好...那么它将变得非常困难。 IP事情已经非常不可能了。它可能是一个GEO-IP库，它导致来自特定区域的IP错误，但是这些都是不太可能的事情。如果以上方法均不能帮助您重现该问题，则可能只是在custom_log_file-call/tcpflow生成的所有数据中均未找到正确的请求。尝试通过获取更准确的时间戳来增加机会。您可以在php中使用microtime()代替date()。检查您的网络服务器，以获取比错误日志中的秒数更准确的信息。编写自己的“tail”实现，可以为您提供更准确的时间戳，...减少系统负载，从而不必从大量数据中进行选择(每天尝试其他时间，用户负载较大)到不同的服务器，...)

一旦可以重现就圈出问题

现在，一旦可以重现，应该在公园散步以找到真正的原因。您可以通过反复试验或将其与导致错误的其他请求进行比较来查找导致错误的参数，以寻找相似之处。然后，您可以看到此参数的作用，哪些库可以访问它，等等。您可以逐个禁用使用该参数的每个组件，直到无法重现为止。然后，您掌握了组件，可以更深入地研究问题。

告诉我们您的发现。我好奇 ;-)。