php 5.3.6 - iis 7.5 - win2k8r2 - fast-cgi:php-cgi.exe 或 FastCgiModule 中的错误

发布于 2025-01-08 11:06:32 字数 724 浏览 2 评论 0原文

您好,我在 php 应用程序中遇到错误,有时会导致事件日志中出现错误,如下所示:

错误应用程序名称:php-cgi.exe,版本:5.3.6.0,时间戳:0x4d81eb28 错误模块名称:php5.dll,版本:5.3.6.0,时间戳:0x4d81ebdc 异常代码:0xc0000005

,有时会出现快速 CGI 错误,没有事件记录错误(可以在本地服务器上浏览):

C:\Program Files (x86)\PHP\v5.3\php-cgi.exe - FastCGI 进程意外退出

在这种情况下,虽然事件日志中没有记录任何错误,但故障后始终紧接着出现以下 2 个条目:

侦听器适配器协议“net.pipe”已成功连接到 Windows 进程激活服务。 侦听器适配器协议“net.tcp”已成功连接到 Windows 进程激活服务。

关于应用程序以何种方式发生故障以及如何记录故障,似乎没有逻辑,但它总是会是其中之一,而且显然它们是相关的。

我们的应用程序相对复杂,但运行正常与运行不正常之间的唯一区别是对数据集的更改,这可能会导致在某些例程中格式化不同的数字。

如果我附加 XDebug (PHP Storm) 并跟踪执行情况,它就会毫无问题地完成。 如果我在没有跟踪的情况下运行,上述故障场景之一就会变得明显。

任何人都可以用我提供的信息解释这种行为,特别是为什么附加调试器并通过应用程序进行跟踪可以防止出现问题?

你会如何调试这个?

谢谢。

Hi I am getting a fault in a php application leading sometimes to an error in the event log as such:

Faulting application name: php-cgi.exe, version: 5.3.6.0, time stamp: 0x4d81eb28
Faulting module name: php5.dll, version: 5.3.6.0, time stamp: 0x4d81ebdc
Exception code: 0xc0000005

And at other times a fast-cgi error with no event logged error (can browse on local server):

C:\Program Files (x86)\PHP\v5.3\php-cgi.exe - The FastCGI process exited unexpectedly

In this case although no error is logged to the event log the following 2 entries always follow directly after the fault:

Listener Adapter protocol 'net.pipe' successfully connected to Windows Process Activation Service.
Listener Adapter protocol 'net.tcp' successfully connected to Windows Process Activation Service.

There is seemingly no logic as to which way the application faults and how it is logged, but it will always be one or the other, and obviously they are related.

Our application is relatively complex, but the only difference between running fine or not running fine is a change to a dataset which may cause different numbers to be formatted in some routines.

If I attach XDebug (PHP Storm) and trace the execution, it completes without issue.
If I run without tracing through, one of the above fault scenarios becomes evident.

Can anyone explain this behaviour with the information I have given, especially why attaching the debugger and tracing through the application prevents the issue?

How would you debug this?

Thanks.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

南薇 2025-01-15 11:06:32

我们的应用程序生成跟踪,但由于输出缓冲区的原因,在发生故障时不会显示该跟踪。

因此,确保跟踪的每一行都显示时间和内存使用情况,我们:

  1. 将跟踪逐行输出到文件。
  2. 比较各种执行的踪迹以找出模式。

就我而言,唯一的模式是内存消耗。成功运行使用的内存少于 60mb,故障运行使用的内存高于 60mb。

应用程序池不支持32位应用程序模式,使得切换到32位模式使内存消耗减半,并且现在一切都像以前一样运行。

顺便说一句,php 在 php.ini 中没有设置内存限制,与应用程序池相同,所以我猜这是一个指针问题,但很高兴再次前进。

Our application generates a trace but due to the output buffer it was not displayed in the case of a fault.

So ensuring that each line of the trace displays time and memory usuage we :

  1. output trace to a file, line by line.
  2. compare trace's of various executions for patterns.

In my case the only pattern was memory consumption. Successful runs used less then 60mb, faulting runs used higher than 60mb.

The application pool was not in support 32 bit application mode, making the switch to 32bit mode halved the memory consumption, and everything now runs as before.

Incidently php has no memory limit set in the php.ini, the same as the app pool so I would guess this was/is a pointer issue, but just happy to be moving forwards again.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文