php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #33363 Crash When memory_get_usage reaches 4868856
Submitted: 2005-06-16 16:24 UTC Modified: 2005-06-17 09:43 UTC
From: asnyder at mddev dot com Assigned:
Status: Not a bug Package: Reproducible crash
PHP Version: 4.3.10 OS: Linux Fedora
Private report: No CVE-ID: None
View Developer Edit
 [2005-06-16 16:24 UTC] asnyder at mddev dot com 
Description:
------------
Here's the problem in the nutshell. For whatever reason a class consisting of a bunch of integers, and strings, appears to take up an additional 500k, when added to the session, or even just to the code. According to my math, it should be around .8 of a KB, not around 500KB, eitherway, what happens is when you keep adding more of these objects, it works until it reaches memory_get_usage of 4868856, which is around 4.6 MB!, when the entire page should only be a few KB( furthermore, if you do memory_get_usage on a blank page it starts with a figure around 14384, why is it any size?)if I'm not mistaken, it doesn't finish rendering all the html. Furthermore, if you add one of these 500KB objects, and then later unset(it and all it's components) it, it only frees up 100KB. Why is this happenning? Why are types taking up so much space, and what can I do to get around this problem?

Asher Snyder

Reproduce code:
---------------
Due to legal reasons, I'm not able to paste any code into this area.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2005-06-16 16:31 UTC] tony2001@php.net 
Please try using this CVS snapshot:

  http://snaps.php.net/php4-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
 [2005-06-16 16:31 UTC] derick@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.
 [2005-06-16 16:41 UTC] asnyder at mddev dot com 
Unfortunately, there would be no way for you to reproduce this bug due to our new technology, but I'm not allowed to explain what that is, or how ti works, but the description should be all you need. Sorry.

Asher
 [2005-06-16 16:44 UTC] derick@php.net 
If you are not willing to provide useful information then we can't help.
 [2005-06-16 16:51 UTC] asnyder at mddev dot com 
I'm trying my best to explain. if I wer eto include code, it would be thousands and thousands of lines of code. This is not a basic PHP script or app, so I can't go into it. If your willing to sign an NDA, I can send you to a link where you can check out the problem yourself.

Can you at least answer why objects take up so much space in the memory?
 [2005-06-16 16:59 UTC] derick@php.net 
How much do you pay?
 [2005-06-16 17:19 UTC] asnyder at mddev dot com 
Our usual consultant pay is 25/hr.
 [2005-06-16 17:48 UTC] asnyder at mddev dot com 
This is not a bogus bug ok. FOr whatever reason, php has insane memory management. AN object with a couple of ints and strings should not take up 500KB, am I the only one that sees something wrong with the average webpage taking up over a meg in memory? Can someone just please tell me what the problem is. Why is it taking up so much, and why can't I free all of it up?
 [2005-06-16 18:01 UTC] sniper@php.net 
Memory usage is in most cases just a bug in your script.
And especially with PHP 4. 

Try the PHP 5.1-dev snapshot:

http://snaps.php.net/php5-latest.tar.gz

And if you can reproduce the bug with that and can provide
us a short reproducing script (yes, really) then reopen this, otherwise keep it bogus.
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Tue Jul 15 14:01:33 2025 UTC