how to obtain a stack trace when WAMP server crashes ?

Question

Hello,

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 ?

Answer 1

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 ;-)

Answer 2

Please see the logs below from the tool debug diagnostics tool with php 5.3.0 debug pack. Is it problem with PDO library that is used to access MySql ?? The crash is very intermittent. Please reply.

Thread 61 - System ID 2760 Entry point msvcrt!_endthreadex+3a Create time 3/31/2010 5:25:46 PM Time spent in user mode 0 Days 0:0:16.593 Time spent in kernel mode 0 Days 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