php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #38190 IIS worker process crash on recycle/shutdown (With cause)
Submitted: 2006-07-23 05:51 UTC Modified: 2006-09-06 21:46 UTC
Votes:12
Avg. Score:4.7 ± 0.6
Reproduced:11 of 12 (91.7%)
Same Version:9 (81.8%)
Same OS:10 (90.9%)
From: cosborne at gmail dot com Assigned: rrichards (profile)
Status: Closed Package: DOM XML related
PHP Version: 5.1.4 OS: Windows Server 2K3
Private report: No CVE-ID: None
View Add Comment Developer Edit
 [2006-07-23 05:51 UTC] cosborne at gmail dot com 
Description:
------------
The IIS worker process (W3WP.exe) crashes with an access violation when the application pool is recycled or IIS is shutdown/restarted.

A number of people have reported this bug, or related bugs, so technically this is a duplicate report, but as I believe I've determined the root cause, I believe it warrants a new report, since the others are in various states, and with various, spurious or conflicting "fixes" and "causes".

Bugs almost certainly related to this include:
#36853
#38111
#37575

Reproduce code:
---------------
Load any PHP script hosted on an IIS server, and either wait for the worker process to be recycled after the specified idle period, or restart IIS.

The IIS worker process (W3WP.exe) will fault. The fault may be "silent", causing an event to be logged.

Expected result:
----------------
The worker process should exit gracefully.

Actual result:
--------------
As part of the PHP shutdown process, xmlGetGlobalState is called, as shown in the following stack trace:
ChildEBP RetAddr  
0007f9b8 01a2d4b4 php5ts!xmlGetGlobalState+0x65
0007f9bc 01a34175 php5ts!__xmlLastError+0x14
0007f9c0 01a457d6 php5ts!xmlResetLastError+0x5
0007f9c4 01a06b63 php5ts!xmlCleanupParser+0x36
0007f9c8 01a06e95 php5ts!php_libxml_shutdown+0x13 [ext\libxml\libxml.c @ 558]
0007f9cc 018472fc php5ts!zm_shutdown_libxml+0x5 [ext\libxml\libxml.c @ 634]
0007f9e4 018dc234 php5ts!module_destructor+0x4c [Zend\zend_API.c @ 1811]
0007f9fc 018dc303 php5ts!zend_hash_apply_deleter+0x24 [Zend\zend_hash.c @ 576]
0007fa0c 018421ee php5ts!zend_hash_graceful_reverse_destroy+0x13 [Zend\zend_hash.c @ 643]
0007fa24 018fbf3a php5ts!zend_shutdown+0x2e [Zend\zend.c @ 730]
0007fa3c 018fbeef php5ts!php_module_shutdown+0x3a [main\main.c @ 1615]
0007fa4c 01832550 php5ts!php_module_shutdown_wrapper+0xf [main\main.c @ 1584]
...
0007fa54 0183268d php5isapi!DllMain+0x70
0007fa74 7c82257a php5isapi!DllMain+0x1ad
0007fa94 7c818145 ntdll!LdrpCallInitRoutine+0x14
0007fba8 77e67b95 ntdll!LdrUnloadDll+0x40e
0007fbbc 5a32843a kernel32!FreeLibrary+0x41
0007fbcc 5a3275a5 w3isapi!ISAPI_DLL::Unload+0x38
0007fbd4 5a327642 w3isapi!ISAPI_DLL::~ISAPI_DLL+0x10
0007fbe0 5a324087 w3isapi!ISAPI_DLL::`scalar deleting destructor'+0xd


xmlGetGlobalState creates a thread that runs xmlGlobalStateCleanupHelper, which simply waits for the calling thread to exit, then frees the global state. Herein lies the problem.

Since the thread on which xmlGlobalStateCleanupHelper is in the process of unloading the php5isapi.dll module (as shown in the stack trace), and hence also unloading php5ts.dll, when this thread finally terminates, and the xmlGetGlobalStateCleanupHelper thread resumes an access violation occurs since the module has been unloaded and the memory is no longer allocated.

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2006-07-23 12:41 UTC] sniper@php.net 
Rob, please take a look, seems to be something you might know about..
 [2006-07-26 14:13 UTC] rrichards@php.net 
I don't have access to a Win 2K3 server, so can't reproduce.
If someone has access to one and can compile source, please try with one of these libxml2 libraries and following changes:
Release: http://ctindustries.net/libxml/libxml2-2.6.17.threads.zip
Debug: http://ctindustries.net/libxml/libxml2-2.6.17.threadsdebug.zip

You will need to add the following somwhere within ext/libxml/libxml.c for now:

PHP_LIBXML_API BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved)
{
	return xmlDllMain(hinstDLL, fdwReason, lpvReserved);
}

Also, you need to use the php_libxml2.def from within the zip and disable xsl support (no current libxslt built against that ver of libxml2).

This libxml2 lib changes the way some of the threading is handled.
 [2006-07-26 23:25 UTC] cosborne at gmail dot com 
It would appear that this has corrected the problem, however I would like to see other people's results before this was considered "fixed"
 [2006-07-26 23:38 UTC] sniper@php.net 
Rob, it works, commit. :)
 [2006-07-29 17:09 UTC] comporder1 at gmail dot com 
When will this fix be released publicly!!! I tired of error messages.
 [2006-07-30 12:38 UTC] rrichards@php.net 
Can you also try with these latest libs (they may be used with the libxslt builds on that page as well to include xsl):
Release: http://ctindustries.net/libxml/libxml2-2.6.26.threads.zip
Debug: http://ctindustries.net/libxml/libxml2-2.6.26.threadsdebug.zip
 [2006-07-30 20:19 UTC] cosborne at gmail dot com 
Once again, it would appear that the bug for which this fix was meant, is solved by these libraries. However this comment still comes with the caveat that I did *not* do a thorough test as to whether other bugs had been introduced, or even whether the xml-related functions still work correctly.
 [2006-07-30 21:31 UTC] rrichards@php.net 
The first step was to see if these would resolve the reported issue. This will not be a quick "fix" for exactly the reasons you mentioned. These libs not only need to be tested with all the extensions, but also with all the different branches (next steps here).

If possible, please continue testing with the new libxml2 libraries and report any new problems you might encounter (again I do not have a W 2K3 server to run these against).
 [2006-08-07 01:00 UTC] php-bugs at lists dot php dot net 
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
 [2006-08-07 18:04 UTC] JustinCouto at msn dot com 
Is there a CVS version with the fixes for the IIS worker process problem in Win2k3?  I need to get this ficed as soo as possible.  Thank!
 [2006-08-18 19:29 UTC] nkennedy at kggroup dot net 
does anyone know if this is resolved in 5.1.5?

any info would be priceless.

Thanks.
 [2006-08-29 13:23 UTC] charles dot nadolski at gmail dot com 
Hello. I am using PHP 5.1.5 and I think I am having the same problem for the same reason:

1) Windows 2003
2) PHP 5.1.5 in ISAPI mode
3) Everything on my PHP page appears to run normally (http://freedombeer.servehttp.com/gallery2)
4) "Random" crashing of w3wp.exe... though because it doesn't occurr during any of my testing of the website, I think my situation also happens when threads are being recycled.  The crashes occurr anywhere from once to four at a time. They also occurr during shutdown of the webserver.

Today:
Application popup: w3wp.exe - Application Error : The instruction at "0x01af5dd0" referenced memory at "0x01af5dd0". The memory could not be "read".

Application popup: w3wp.exe - Application Error : The instruction at "0x01af5dc0" referenced memory at "0x01af5dc0". The memory could not be "read".

Yesterday:
Application popup: w3wp.exe - Application Error : The instruction at "0x01af5dd0" referenced memory at "0x01af5dd0". The memory could not be "read".

Application popup: w3wp.exe - Application Error : The instruction at "0x01af5dd0" referenced memory at "0x01af5dd0". The memory could not be "read".

Ad nauseam, usually from the same memory location even after a reboot.

Since I have visual studio installed I'll hit the debugger to check to make sure it is the *exact* same problem.  If not, I'll post a new bug.
 [2006-09-03 10:34 UTC] taomyn at myway dot com 
Yes, can someone point us at a binary we can download and test that might fix this extremely annoying issue?

It's not like you haven't been told what the cause is and how to fix it. Yes it needs testing but I suspect you have plenty of volunteers here.

It still doesn't work with 5.1.6 as I assume whatever fix (if it really exists) is only being worked on for 5.2
 [2006-09-06 21:46 UTC] edink@php.net 
Fixed in the CVS. Will be included in upcoming 5.2.0 release and should appear on snaps.php.net in a few hours.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Sat Apr 27 23:01:30 2024 UTC