php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #20666 Array handling within objects crash (obscure)
Submitted: 2002-11-26 22:43 UTC Modified: 2002-12-06 19:17 UTC
Votes:1
Avg. Score:5.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:1 (100.0%)
From: radio at soulnet dot tk Assigned:
Status: No Feedback Package: Reproducible crash
PHP Version: 4.2.3 OS: Windows 2000
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: radio at soulnet dot tk
New email:
PHP Version: OS:

 

 [2002-11-26 22:43 UTC] radio at soulnet dot tk
Within the object template, I have the following code which is valid (see bottom). It is a caching mechanism where $this->blocks[$handle] is a piece of html delimited by <!--##START.NAME##--><!--##END.NAME##-->, you get the idea. An attempt to implement a caching system was met with a crash. The problem appears to be somewhere within the means by which arrays are handled. 

I used the following setup when reproducing this crash:

Server: Win32 Apache 1.3.26
PHP Installation: SAPI Module via php4apache.dll
OS: Windows 2000 Professional Service Pack 3

I have reason to believe that this may exist in the global code as well as after testing it on another server, the array indices did not return a value when set.

The alternate server (http://soulnet.tk):
OS: Windows XP
CPU: Dual Intel Pentiums 232Mhz (each)
Server: OmniHTTPD 1.0.1
PHP Installation: CGI-Binary

=============================================

function tpl_seek ( $handle , $name ) 
{

	$name = strtoupper ( $name );
		
if ( isset ( $this->tpl_cache[$handle][$name] ) ) return $this->cache[$handle][$name];
		
	if ( preg_match ( "/<!--##START\.$name##-->(.+?)<!--##END\.$name##-->/si" , $this->blocks[$handle] , $matches ) )
	{
		$this->tpl_cache[$handle][$name] = $matches[1];
		$this->current = $matches[1];
		return TRUE;
	}

	return FALSE;
}

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2002-11-26 22:48 UTC] radio at soulnet dot tk
Within the object template, I have the following code which is valid
(see bottom). It is a caching mechanism where $this->blocks[$handle] is
a piece of html delimited by <!--##START.NAME##--><!--##END.NAME##-->,
you get the idea. An attempt to implement a caching system was met with
a crash. The problem appears to be somewhere within the means by which
arrays are handled. 

I used the following setup when reproducing this crash:

Server: Win32 Apache 1.3.26
PHP Installation: SAPI Module via php4apache.dll
OS: Windows 2000 Professional Service Pack 3

I have reason to believe that this may exist in the global code as well
as after testing it on another server, the array indices did not return
a value when set.

I should also note that this a rather obscure bug (rather obvious), however the results are the same on every execution attempt. Removing the calls to this array seem to remove this problem. However further research showed that the first call is benign. The second call to that array indice causes a crash.

The alternate server (http://soulnet.tk):
OS: Windows XP
CPU: Dual Intel Pentiums 232Mhz (each)
Server: OmniHTTPD 1.0.1
PHP Installation: CGI-Binary

=============================================

function tpl_seek ( $handle , $name ) 
{

	$name = strtoupper ( $name );
		
if ( isset ( $this->tpl_cache[$handle][$name] ) ) return
$this->cache[$handle][$name];
		
	if ( preg_match (
"/<!--##START\.$name##-->(.+?)<!--##END\.$name##-->/si" ,
$this->blocks[$handle] , $matches ) )
	{
		$this->tpl_cache[$handle][$name] = $matches[1];
		$this->current = $matches[1];
		return TRUE;
	}

	return FALSE;
}
 [2002-11-26 23:21 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

First of all, test this with latest snapshot.
If this problem still happens with the snapshot too,
then provide us a complete, self-contained example
script which can be easily copy'n'pasted and run.

 [2002-12-05 17:45 UTC] michiwalter at gmx dot de
I have a rather similar problem:

Platform:
- Windows 2000 SP 3
- Apache 1.3
- crash happens on both SAPI and CGI
- PHP 4.2.3

The crash does NOT happen under Windows XP using the same setup, only under Windows 2000 !

Description:

I experience a similar problem as the original author of the bug note - in a member function ("within objects") I'm creating/adding items to a hash array ("array handling") which contains pairs of string=>object instance.

Once I access that array, tho, by using foreach(), it makes PHP crash (same happens with while(list=each), but NOT with a for() on the array_keys()). Even tho I thought that I had a work-around using the mentioned for() over array_keys() of the hash array, it made my application crash at another position, too - a position where I'm just accessing a particular array member via it's hash key.

Somehow, here I can only guess, PHP seems to have a problem that corrupts my array - which then makes PHP crash. From the error message (invalid write operation) I suspect that there's some invalid pointer stuff going on, but again, I can only guess.

I'm sorry that I can't give a reproducing piece of code, but that is the first time the problem occured and I wasn't able to simplify the code and track it down yet.
 [2002-12-06 19:17 UTC] sniper@php.net
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.


 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Wed Apr 24 14:01:30 2024 UTC