php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #35506 FATAL: erealloc(): Unable to allocate 24576 bytes
Submitted: 2005-12-01 17:35 UTC Modified: 2005-12-07 00:12 UTC
From: broadmind at magicn dot com Assigned:
Status: Not a bug Package: Reproducible crash
PHP Version: 5CVS-2005-12-03 (snap) OS: windows 2000 server
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: broadmind at magicn dot com
New email:
PHP Version: OS:

 

 [2005-12-01 17:35 UTC] broadmind at magicn dot com
Description:
------------
My server environment is,

CPU : AMD Opteron 240 x2 (2 cpu)
RAM : 2 GB
Apache 1.3.34
Mysql 5.0.16
PHP : 5.1.2-dev Snap stable version.

In error logs, I could find the following error message frequently.

FATAL:  erealloc():  Unable to allocate 24576 bytes

So, opening windows task manager, I have monitored the memory usage of Apache server.
I found this log is happen when it is over 240MB duing to heavily access to mysql through a PHP page.
Because the memory size of my server is 2GB, it is nonsense to say that this problem is duing to the lack of memory.
In my guess, there may be a memory leak in the memory manager.

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

the above log is leaved in error.log file and Apache server is restarted, causing the lose of POST data or "page not found".


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2005-12-04 16:42 UTC] broadmind at magicn dot com
I know that this problem comes from lots of mysql requests, but as a result of having a lot of tests, it may be due to the "include" statement, because my php codes have many "include" statements.

For your test, my example codes is here.
(the following codes are just for a test, not real codes)

http://www.brickart.co.kr/logs/board.php.doc
http://www.brickart.co.kr/logs/menu_search.php.doc

1) Please download these files and remove ".doc" suffix.
2) Run Windows task manager.
3) Please run board.php with your web browser.
4) To refresh this page, please press F5 key down continuously. (don't let it be pushed up)

You can see the memory usage of Apache is only incremented.
When it is over about 230MB, the process will be destroyed.
 [2005-12-06 04:03 UTC] sniper@php.net
I can't reproduce this. Do you load any Zend extensions, such as APC, Zend Optimizer, Xdebug or any other debugger/cache/etc. in your php.ini?
 [2005-12-06 05:04 UTC] broadmind at magicn dot com
No, I didn't load any Zend extensions and debug modules.
Please try with the increased iteration number in board.php..

(In addition, I could reproduce this with Apache server on  windows 2000 professional)
 [2005-12-06 20:26 UTC] iliaa@php.net
Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.  Due to the volume
of reports we can not explain in detail here why your report is not
a bug.  The support channels will be able to provide an explanation
for you.

Thank you for your interest in PHP.

The error you are seeing is the direct result of a native memory allocation function failing to allocate memory. PHP merely reports the failure as it was returned to it by the OS.
 [2005-12-07 00:12 UTC] broadmind at magicn dot com
This is not a bug?? Poop..
This problem didn't occur in php 4.3.x early version.
I think your team is very poor in dealing with a bug report.
Ok ok, I had better convert php scripts into ASP or JAVA script.
Thanks for your support!
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Tue May 07 22:01:30 2024 UTC