WAMP 服务器崩溃时如何获取堆栈跟踪？

发布于 2024-08-25 01:09:51 字数 631 浏览 5 评论 0原文

有时我的 WAMP 服务器崩溃。我收到以下错误。

HTTP has encountered exception and needs to close.
Unreferenced Memory.
szAppName : httpd.exe     szAppVer : 2.2.11.0     szModName : php5ts.dll     
szModVer : 5.3.0.0     offset : 0000c309     


C:\DOCUME~1\blrcom\LOCALS~1\Temp\WERc677.dir00\httpd.exe.mdmp
C:\DOCUME~1\blrcom\LOCALS~1\Temp\WERc677.dir00\appcompat.txt

我的问题是如何获取堆栈跟踪来调试这个问题？我应该使用 Windows 调试器 Windows 调试器或者我应该启用 WAMP 服务器配置中的某些设置吗？

原文

Some times my WAMP server crashes . I get the following error.

HTTP has encountered exception and needs to close.
Unreferenced Memory.
szAppName : httpd.exe     szAppVer : 2.2.11.0     szModName : php5ts.dll     
szModVer : 5.3.0.0     offset : 0000c309     


C:\DOCUME~1\blrcom\LOCALS~1\Temp\WERc677.dir00\httpd.exe.mdmp
C:\DOCUME~1\blrcom\LOCALS~1\Temp\WERc677.dir00\appcompat.txt

My question is how to obtain stack trace to debug this problem ?
Should I use a windows debugger windows debugger
or is there some setting in WAMP server configuration should i enable ?

分享到QQ

分享到微博

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

发布评论

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

顾挽 2024-09-01 01:09:51

您可以使用调试诊断< /a>.
在启动 Debug Diag 时弹出的“选择规则类型”对话框中选择“崩溃”规则。

另请查看 Tess Ferrandez 博客条目使用 Debug Diag 1.1 调试本机内存泄漏。（虽然它不完全是您想要的，但阅读该博客永远都不会错;-)）

调试符号包含将可执行文件和代码“粘合”在一起的信息。 Microsoft 的调试符号格式称为“程序数据库”，它们通常存储在扩展名为 .pdb 的文件中。
现在你只能得到“php5ts!zend_mm_shutdown+f69 处的汇编指令”。应用程序调用由 php5ts.dll 导出的函数 zend_mm_shutdown，因此调试器“知道”该函数，无论是否存在调试符号。但它不知道导致编译器在 zend_mm_shutdown+f69 处构建机器指令的源代码。调试符号包含此类信息，因此调试器可以向您显示源代码和上下文。
您可以为调试和发布版本创建调试符号（对于后者，它们通常不太准确）。但我还没有找到 php 的 wamp 版本的调试包。
对于 php.net/win32 版本，您可以从 http://windows 下载其发布版本的调试包。 php.net/download/。或者您可以下载源代码并自行创建调试版本。但是您不能将 wamp 可执行文件与 php.net 调试包混合使用（即您不会为此使用 wamp 可执行文件/dll）。

也许查看源代码可以给您提示哪里出了问题。但不知何故我对此表示怀疑。 zend_mm_shutdown 中的 mm 可能代表“内存管理”。它可能只是释放了一些内存桶，并且它的一些数据结构在这一点上是错误的。这可能是其他一些代码覆盖了 zend 内存管理的数据。可能是处理错误的边缘情况（已释放但未从列表/数据结构中删除的内容）。坏事是根本问题可能在任何地方……远离最终导致访问冲突的代码。如果 zend_mm_shutdown 确实是一些低级内存管理，那么关于什么改变了数据结构（以及原因），可能就没有太多信息了。
我宁愿先尝试另一个 php 构建，看看问题是否再次出现。用 php.net 构建替换 wamp 文件应该不难。它可能就像替换 wamp 安装中的 php 文件夹一样简单，然后查看是否也需要将一些文件复制到 apache 二进制文件夹。
但首先要复制/备份整个 wamp 文件夹......以防万一;-)

You can use Debug Diag.
Select the "Crash" rule in the "Select Rule Type" dialog that pops up when you start Debug Diag.

Also take a look at Tess Ferrandez blog entry Debugging Native memory leaks with Debug Diag 1.1. (Though it's not exactly about what you want, it's never wrong to read that blog ;-))

Debug Symbols contain information that "glue" the executable and the code together. Microsoft's format for debug symbols is called "program database" and they are usually stored in files having the extension .pdb.
Right now you only get "the assembly instruction at php5ts!zend_mm_shutdown+f69". The application called into a function zend_mm_shutdown that is exported by the php5ts.dll, so the debugger "knows" about this function regardless of whether there are debug symbols or not. But it doesn't know about the source code that led the compiler to build the machine instruction at zend_mm_shutdown+f69. The debug symbols contain such information, so a debugger can show you the source code and the context.
You can create debug symbols for both the debug and the release build (for the latter they are usually less accurate). But I haven't found a debug pack for the wamp builds of php.
For the php.net/win32 build you can download the debug packs for their release builds from http://windows.php.net/download/. Or you can download the source code and create a debug build yourself. But you can't mix the wamp executable with the php.net debug packs (i.e. you wouldn't use the the wamp executables/dlls for this).

And maybe seeing the source code can give you a hint about what's going wrong. But somehow I doubt that. The mm in zend_mm_shutdown probably stands for "memory management". It probably just releases some buckets of memory and some of its data structures are wrong at this point. That could be some other code overwriting data of the zend memory management. Could be an edge case that is handled wrong (something that has been freed but not removed from the list/data structure). The bad thing is the underlying problem could be anywhere ...far, far away from the code that is finally causing the access violation. And if zend_mm_shutdown really is some low-level memory management there's probably not much information left about what changed the data structure (and why).
I'd rather try another php build first and see if the problem occurs again. It shouldn't be to hard to replace the wamp files by the php.net build. It might be as easy as to replace the php folder in your wamp installation and then look if you have to copy some files to the apache binary folder, too.
But make a copy/backup of the complete wamp folder first ....just in case ;-)

回复收藏 0 原文

深爱成瘾 2024-09-01 01:09:51

请使用 php 5.3.0 调试包查看以下工具调试诊断工具的日志。
用于访问MySql的PDO库是否有问题？
崩溃是非常间歇性的。请回复。

线程 61 - 系统 ID 2760
入口点 msvcrt!_endthreadex+3a
创建时间 2010年3月31日 5:25:46 PM
用户模式花费的时间 0 天 0:0:16.593
内核模式花费的时间 0 天 0:0:0.453

Function Arg 1 Arg 2 Arg 3 Source
php5ts!_zend_mm_free_int+139 0288a878 00020004 008eff46
php5ts!_efree+36 0110ff48 02d18868 0090e442
php5ts!_zval_ptr_dtor+66 024ffa88 02d18770 02d18848
php5ts!zend_std_write_property+1f2 02d18848 0110ff48 02d18868
php5ts!pdo_stmt_construct+7d 02d1b968 02d18848 0110eb90
php5ts!zim_PDO_prepare+428 0110eb90 02d18848 00000000
php5ts!zend_do_fcall_common_helper_SPEC+946 024ffbf8 028894c8 024ffe74
php5ts!execute+29e 02d40070 02889400 00000000
php5ts!zend_execute_scripts+f6 00000008 028894c8 00000000
php5ts!php_execute_script+22d 024ffe74 028894c8 00000005
php5apache2_2!php_handler+5d0 03249f98 008238b8 03249f98
libhttpd!ap_run_handler+21 03249f98 03249f98 03249f98
libhttpd!ap_invoke_handler+ae 00000000 029e9fd8 024fff38
libhttpd!ap_die+29e 03249f98 00000000 00788168
libhttpd!ap_get_request_note+1c9c 029e9fd8 029e9fd8 029e9fd8
libhttpd!ap_run_process_connection+21 029e9fd8 00775050 024fff80
libhttpd!ap_process_connection+33 029e9fd8 027de3f0 00ed0000
libhttpd!ap_regkey_value_remove+c7c 029e9fd0 00ed0000 00f10000
msvcrt!_endthreadex+a9 011d3088 00ed0000 00f10000
kernel32!BaseThreadStart+37 77c3a341 011d3088 00000000