#20666 [Opn->Fbk]: Array handling within objects crash (obscure)
| From: | sniper@php.net | Date: | Wed, 27 Nov 2002 05:21:01 +0000 |
| Subject: | #20666 [Opn->Fbk]: Array handling within objects crash (obscure) | ||
| References: | 1 | Groups: | php.bugs |
| Request: | Send a blank email to php-bugs+get-25935@lists.php.net to get a copy of this message | ||
ID: 20666
Updated by: sniper@php.net
Reported By: radio@soulnet.tk
-Status: Open
+Status: Feedback
Bug Type: Reproducible crash
Operating System: Windows 2000
PHP Version: 4.2.3
New Comment:
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.
Previous Comments:
------------------------------------------------------------------------
[2002-11-26 22:48:48] radio@soulnet.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 22:43:48] radio@soulnet.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;
}
------------------------------------------------------------------------
--
Edit this bug report at http://bugs.php.net/?id=20666&edit=1