php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #13324 Access violations / memory problems
Submitted: 2001-09-15 19:45 UTC Modified: 2002-10-15 01:00 UTC
Votes:5
Avg. Score:4.8 ± 0.4
Reproduced:5 of 5 (100.0%)
Same Version:2 (40.0%)
Same OS:4 (80.0%)
From: txtilde at hotmail dot com Assigned:
Status: No Feedback Package: IIS related
PHP Version: 4.0.6 OS: Windows 2000 SP2
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: txtilde at hotmail dot com
New email:
PHP Version: OS:

 

 [2001-09-15 19:45 UTC] txtilde at hotmail dot com
This is a fresh install of PHP 4.0.6 on a new install of Windows 2000 server with service pack 2.  Zend Optimizer is installed and the site is in Medium (pooled) mode.  I am using the php4isapi.dll.  There are no other programs or services installed on this machine.

The code executing is a single pconnect request to a MYSQL server and then a mysql_close() request.  The code is not Zend optimized.

If I enable ZendOptimizer.dll in the php.ini and execute the code, it operates fine.  But if I reset the IIS service, the server returns the following 2 errors randomly:

1) -2147417842 (0x8001010e)
2) Invalid access to memory location.

If I comment out the ZendOptimizer.dll in the PHP.ini file and then restart the web service, operation resumes as normal.

I believe the IIS Web Service is not releasing the ZendOptimizer.dll from memory and then trying to reload it when PHP is called.  This may be a hint to all the access violations every one is getting.

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2001-09-15 20:12 UTC] txtilde at hotmail dot com
As a follow-up, with ZendOptimizer.dll uncommented in the php.ini file:

Each IIS restart and request to the php webpage will result in a new instance DLLHOST.exe being created in the Windows Task Manager.  Older DLLHost.exe instances are not released with IIS Reset.
 [2001-09-15 20:50 UTC] txtilde at hotmail dot com
After further investigation, this seems to be a hint to a higher IIS threading problem rather than a problem specific to Zend Optimizer.  If I create a php page with the function getmicrotime() in it and then call this page from 5 different browser windows at about the same time, I receive the following error:

Fatal error: Cannot redeclare getmicrotime() in C:\Websites\mysqlconnect.php on line 2

I've also confirmed that variables declared within the realm of the script are also available to other browser sessions.  For example, creating a random number in a script and then executing a time consuming for-loop will result in more than one window ending up with the same random number.
 [2002-02-19 08:55 UTC] pthiebaud at labeltechnologies dot com
Are you using Zendencoder? I have the same problem on a machine running Zendoptimizer with some pages that were Zendencoded. The server crashed every 20-30 request or so. I took off the pages Zendencoded and its working fine now... Seems that the problem stands there...It is not the Zendoptimizer, cause it is still in the php.ini and it works fine.
 [2002-03-26 17:43 UTC] mail-php dot net at kimihia dot org dot nz
I've reproduced this without Zend Optimizer.

Under heavy load (45 requests / second) I received a number of errors about being unable to redeclare functions.

Under low load there were no complaints.

PHP 4.2.0 / IIS 5 / Windows 2000
 [2002-06-03 12:17 UTC] mfischer@php.net
Dup of 15333
 [2002-09-29 20:26 UTC] sniper@php.net
Please try using this CVS snapshot:

  http://snaps.php.net/php4-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-latest.zip


 [2002-10-15 01:00 UTC] php-bugs at lists dot php dot net
No feedback was provided for this bug for over 2 weeks, 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".
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Tue Mar 19 11:01:28 2024 UTC