php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #38124 FATAL: erealloc(): Unable to allocate xxx bytes
Submitted: 2006-07-17 12:05 UTC Modified: 2008-01-21 13:49 UTC
Votes:6
Avg. Score:4.2 ± 0.9
Reproduced:6 of 6 (100.0%)
Same Version:2 (33.3%)
Same OS:3 (50.0%)
From: boing at boing dot com Assigned:
Status: No Feedback Package: DOM XML related
PHP Version: 5.1.4 OS: openbsd 3.8
Private report: No CVE-ID: None
 [2006-07-17 12:05 UTC] boing at boing dot com
Description:
------------
I'm getting this:

FATAL:  erealloc():  Unable to allocate 3358824 bytes

The process only allocates approximately 30Megs (according to top and ps).  I've increased the ulimits to beyond 256Megs.  I've also run php test scripts with different memory allocation and str_repeats and such to create a large processes.  All work well.  In addition I wrote c code to bang on realloc(3) in openbsd.  I know there is plenty of ram left.  But this code does get pretty ugly with multiple levels of associative arrays.  I'm happy to help out any way I can.

Reproduce code:
---------------
http://www.boing.com/phptest.tgz - contains the phptest.php script and in a directory, the data file extensions.xml.gz.  I stripped down the typo3.org cms code that pulls in their "new extensions" such that code to reproduce is here.  I turned it into a standalone file.  And it all started out as a research project...

php phptest.php

I've tried many different configure options, but this is the current attempt: ./configure --prefix=/usr/local/php5 --with-apxs2=/usr/local/apache2/bin/apxs --with-mysql --with-pgsql=/usr/local/pgsql --with-ldap=/usr/local/openldap --with-pear --with-zlib  --with-libexpat-dir=/usr/local/shared

Expected result:
----------------
a file called extensions.bin that should be the serialized output of the nasty looking array.  Hey I didn't write the original code, I'm just the messenger. :)  I definitely don't expect it to not be able to allocate 3 megs.

Actual result:
--------------
FATAL:  erealloc():  Unable to allocate 3358824 bytes

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2006-07-17 13:02 UTC] boing at boing dot com
BTW - openbsd 3.8 package of php 5.0.4 exhibits the same behavior.  package name:  php5-core-5.0.4p0
 [2006-07-17 20:01 UTC] mike@php.net
Please try using this CVS snapshot:

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

Works fine here (Linux).
 [2006-07-17 21:22 UTC] boing at boing dot com
Thanks for the speedy response!

I tried in linux also, works well in gentoo, not in openbsd.  :( But openbsd has some weird stuff going on: propolice, etc.  Windows has marks on it where I've been touchin in with the 10 foot poll.

course the usual bsd analities result in the linking stage:
main/.libs/php_sprintf.o(.text+0x24): In function `php_sprintf':
/usr/local/src/php5.2-200607172030/main/php_sprintf.c:38: warning: vsprintf() is often misused, please use vsnprintf()
ext/pdo/.libs/pdo_dbh.o(.text+0x37): In function `pdo_raise_impl_error':
/usr/local/src/php5.2-200607172030/ext/pdo/pdo_dbh.c:60: warning: strcpy() is almost always misused, please use strlcpy()
ext/sqlite/libsqlite/src/.libs/btree.o(.text+0x46ba): In function `checkRef':
/usr/local/src/php5.2-200607172030/ext/sqlite/libsqlite/src/btree.c:3201: warning: sprintf() is often misused, please use snprintf()
ext/mysql/.libs/php_mysql.o(.text+0x5007): In function `php_mysql_field_info':
/usr/local/src/php5.2-200607172030/ext/mysql/php_mysql.c:2418: warning: strcat() is almost always misused, please use strlcat()

script results w/ php5.2-200607172030:  (same thing, slightly different byte count, of course)

kusanagi:/usr/local/apache2/htdocs)unlimit
kusanagi:/usr/local/apache2/htdocs)limit
cputime      unlimited
filesize     unlimited
datasize     262144 kbytes
stacksize    32768 kbytes
coredumpsize unlimited
memoryuse    392364 kbytes
descriptors  1024
memorylocked 392364 kbytes
maxproc      512
kusanagi:/usr/local/apache2/htdocs)ls -la typo3temp/extensions.xml.gz
-rw-r--r--  1 boing  wheel  599305 Jul 17 02:32 typo3temp/extensions.xml.gz
kusanagi:/usr/local/apache2/htdocs)/usr/local/php52/bin/php phptest.php
start handler<br>
new handler<br>
parsing......<br>
<p>The extensions list has been updated and now contains 1777 extension entries.</p><br>
saving...<br>
FATAL:  erealloc():  Unable to allocate 3346466 bytes
 [2006-07-17 21:35 UTC] boing at boing dot com
This is going to sound dumb, but does php have a limit on the size of an associative array?  Or the number of multi-dimensional associative arrays that are part of one variable?  I've googled for these types of things with no results.
 [2006-07-18 06:45 UTC] tony2001@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with <?php and ends with ?>,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc.

If possible, make the script source available online and provide
an URL to it here. Try to avoid embedding huge scripts into the report.


 [2006-07-18 09:55 UTC] boing at boing dot com
tony2001@php.net,

I put the reproduce code in the original bug report.  THe files are still on my website.  In addition, I don't think it's DOM XML related.  My money WAS on xml_parse in the beginning, but no longer.  I think it's on the associative arrays. :)

reproduce code again... download:  http://www.boing.com/phptest.tgz
inside there is a phptest.php and a datafile.  php phptest.php on openbsd 3.8 will yield the failture to realloc.  I tried it on gentoo with successful results.

Geff
 [2006-07-18 10:23 UTC] tony2001@php.net
>I put the reproduce code in the original bug report
Yes, I saw it. Please try to make is as smaller as you can. Currently it's just HUGE, that's why asked for a short and complete script which is max 20 lines long.

Please also try the latest 5.2 snapshot which you can grab at http://snaps.php.net (wait for the next one, there was a major change in the memory manager recently).
 [2006-07-18 10:51 UTC] boing at boing dot com
Honestly, I trimmed it down as much as possible.  Most of the file is the data it operates on. Some big, ugly (yes, that's redundant :) ) xml file.  You should see the original code.  Lot's more trash in there.  Honest.  :)  I think the realloc() failure has something to do with the length of the file and building the sufficiently complex nested associative array uglyness.

Geff
 [2006-07-18 13:01 UTC] tony2001@php.net
Please try using this CVS snapshot:

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


 [2006-07-26 01:00 UTC] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, 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".
 [2008-01-21 11:34 UTC] mryaggi at hotmail dot com
I have FATAL: erealloc(): Unable to allocate 2 bytes 

when doing :

imagecreatetruecolor and then imagefill
on an image I use as a brush.

if i switch imagefill for an imagefilledrectangle (with the image dimensions) it works fine.


Config : PHP4.4.1 on IIS7
 [2008-01-21 13:49 UTC] pajoye@php.net
"if i switch imagefill for an imagefilledrectangle (with the image
dimensions) it works fine."

Thatg's expected and unrelated to the current issue. To draw a filled rectangle on an image requires no additional memory (except the heap). That's not the case for a flood fill.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Dec 13 10:01:28 2024 UTC