WAMP sunucu çöküyor zaman bir yığın izlemesi edinme?

1 Cevap php

Bazı kere benim WAMP sunucu çöküyor. Ben şu hatayı alıyorum.

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 ?

1 Cevap

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

Ayrıca Tess FERRANDEZ blog girdisinde bakmak Debugging Native memory leaks with Debug Diag 1.1. (Tam olarak ne istediğinizi değil de, o ;-) bu blog okumak için never yanlış)

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

etiketler