BTW - openbsd 3.8 package of php 5.0.4 exhibits the same behavior.  package name:  php5-core-5.0.4p0

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).

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

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.

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.

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

>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).

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

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

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".

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

"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.