#32738 [Bgs]: large array keys causes memory corruption and segfaults
ID: 32738
User updated by: pvandijk at gmail dot com
Reported By: pvandijk at gmail dot com
Status: Bogus
Bug Type: Reproducible crash
Operating System: Linux 2.4.22-1.2115.nptl
PHP Version: 4.3.11
New Comment:
Perhaps the reason i was unable to find the previous error reports is
that they seem to date back to 2002.
If this is indeed the same issue as Bug #16149 then i'm a little
puzzled as to why it hasnt been fixed over the past 3 years. maybe the
issue is more complex than just changing the ushort refcount, to a uint
in the _zval_struct?
Previous Comments:
[2005-04-18 08:42:31] [EMAIL PROTECTED]
Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same.
Thank you for your interest in PHP.
This is because we have a 2 byte refcount counter. You're adding too
many (internal) references to $data overflowing the counter. When it
hits zero the data is free and you can't access it anymore - resulting
in the segfault.
[2005-04-18 02:50:16] pvandijk at gmail dot com
Description:
Hashes with a large number of keys and large key data size seem to
cause memory corruption, which in turn causes php to either segfault or
hang upon exiting (depending on the context of the code).
I've heard mention that arrays are not unlimited in size. This issue
seems to occur at about 65535 elements in my tests, but also depends on
the size of the keys. Presumably this is because i'm indexing my arrays
with Strings, and therefore it's running out of memory faster.
If the memory limit of a hash is reached, should it not be handled more
gracefully than corrupting memory, which results in a segfault?
The code example i've provided seems to reproduce a crash under both
linux and windows, php 4.3.11
Reproduce code:
---
?php
$data = 'hello, i like cheese';
$ar = array();
for($i = 100; $i 300 ; $i++) {
$key = 'abc'.$i;
$ar[$key] = $data;
}
function check($ar) {
global $data;
foreach($ar as $k = $value) {
if($data != $value) {
print 'invalid value: '. $k .' = '. $value .\r\n;
}
}
}
check($ar);
print 'done.'.\r\n;
?
Expected result:
done.
Actual result:
--
done.
Segmentation fault
sorry i cant provide a backtrace or any further info, i dont have
access to these tools on my current dev server.
--
Edit this bug report at http://bugs.php.net/?id=32738edit=1
#32738 [NEW]: large array keys causes memory corruption and segfaults
From: pvandijk at gmail dot com
Operating system: Linux 2.4.22-1.2115.nptl
PHP version: 4.3.11
PHP Bug Type: Reproducible crash
Bug description: large array keys causes memory corruption and segfaults
Description:
Hashes with a large number of keys and large key data size seem to cause
memory corruption, which in turn causes php to either segfault or hang
upon exiting (depending on the context of the code).
I've heard mention that arrays are not unlimited in size. This issue seems
to occur at about 65535 elements in my tests, but also depends on the size
of the keys. Presumably this is because i'm indexing my arrays with
Strings, and therefore it's running out of memory faster.
If the memory limit of a hash is reached, should it not be handled more
gracefully than corrupting memory, which results in a segfault?
The code example i've provided seems to reproduce a crash under both linux
and windows, php 4.3.11
Reproduce code:
---
?php
$data = 'hello, i like cheese';
$ar = array();
for($i = 100; $i 300 ; $i++) {
$key = 'abc'.$i;
$ar[$key] = $data;
}
function check($ar) {
global $data;
foreach($ar as $k = $value) {
if($data != $value) {
print 'invalid value: '. $k .' = '. $value .\r\n;
}
}
}
check($ar);
print 'done.'.\r\n;
?
Expected result:
done.
Actual result:
--
done.
Segmentation fault
sorry i cant provide a backtrace or any further info, i dont have access
to these tools on my current dev server.
--
Edit bug report at http://bugs.php.net/?id=32738edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32738r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=32738r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=32738r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=32738r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=32738r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=32738r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=32738r=needscript
Try newer version: http://bugs.php.net/fix.php?id=32738r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=32738r=support
Expected behavior: http://bugs.php.net/fix.php?id=32738r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=32738r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=32738r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=32738r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32738r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=32738r=dst
IIS Stability: http://bugs.php.net/fix.php?id=32738r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=32738r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=32738r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=32738r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=32738r=mysqlcfg
