Call for testing a critical fix in WINCACHE RTW 1.0
There has been several instances where people using WINCACHE have reported problem while running it on the actual production server. They have complained that WINCACHE works very well on development server but the users can see a crash (or different symptoms of it) while actually deploying it on a live production server. I am pasting some of the forum links where these kind of problems have been reported:
http://forums.iis.net/t/1163921.aspx
http://forums.iis.net/t/1163114.aspx
As one can see there are various symptoms of this. Users can start getting a blank page or PHP can stop responding. And eventually there will a crash report in the Windows Event Viewer which will be something similar to:
Faulting application php-cgi.exe, version 5.2.11.11, time stamp 0x4ab13019, faulting module php_wincache.dll, version 1.0.819.0, time stamp 0x4a8e6f87, exception code 0xc0000005, fault offset 0x000029be, process id 0x37c, application start time 0x01ca3d975761fce0.
The developer on the team was finally able to figure out the actual problem. As per him,
Crashes were happening because refcounts of global aplist filemap and global opcode cache filemap were going out of sync. When a local opcode cache filemap get created, this process doesn’t increment refcount of filemap which holds global opcode cache but still increment the refcount of filemap used to store global aplist. As new php-cgi processes gets created and killed, this difference in refcounts keep going high and reaches a point where refcount for global opcode cache hits zero but global aplist is positive. At this point all opcode cache offsets in global aplist are invalid. Now the next php-cgi process which gets launched creates a new global opcode cache filemap and but uses existing global aplist. This process will crash when it uses old opcode cache offsets from the aplist because those are not valid for brand new opcode cache. I have fixed the bug by making global aplist set opcode cache offsets to 0 when we detect that a new global opcode cache is created.
This has been a very critical fix. Since I was never able to reproduce it, I would like this to be validated by all of the user’s out there who have seen the crash. Please take time to validate this critical fix. If you want to get the binaries please write a mail to one of the email id specified below specifying whether you are interested in PHP 5.2 or PHP 5.3 version of WINCACHE DLL. The email ids to reach for is:
- ruslany[at]microsoft[dot]com {Program Manager on the WINCACHE team}
- ksingla[at]microsoft[dot]com {Developer on the WINCACHE team}
- donraman[at]microsoft[dot]com {Tester on the WINCACHE team}
I am on vacation till the end of this week and hence I will prefer to use first two mailing ids.
I would personally like this fix to address all the crashes being observed in WINCACHE by the users above. It is very important for you all using WINCACHE and seeing the above bad behavior to look at the new binary, try it and report any problem if it still persists. We want to address all the above crashes which will eventually be packaged/bundled together and released as WINCACHE 1.0.1. So please come forward and help us. We did test it on Ruslaan’s server (http://www.ruslany.net) and now it is no longer crashing (It does use to crash before). So we do have some sort of validation on our side.
This fix closes the bug at http://pecl.php.net/bugs/bug.php?id=16975. The actual code for the fix can be found at http://svn.php.net/viewvc?view=revision&revision=293718 for people interested.
Happy testing and thanks for helping the WINCACHE team. And till we meet again ‘Good Bye’.
Thanks,
Don.