5

I get the following error:

[23-Feb-2011 19:51:29] PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 512 bytes) in /obj/class.db.php on line 60

My problem is that I don't know where this error happens. Line 60 of class.db.php is one of the most used functions in my application (Database Read() function).

How can I trace back where this error originates from?

hakre
  • 193,403
  • 52
  • 435
  • 836
Norwald2
  • 695
  • 4
  • 9
  • 19
  • 1
    You may want to take a look at: http://stackoverflow.com/questions/880458/php-memory-profiling –  Feb 23 '11 at 19:01
  • You are be able to get the callstack... Tried searching @ php.net? debug_backtrace http://php.net/manual/en/function.debug-backtrace.php Other way of good information is create your own ExceptionHandlers... Example over here: http://www.edmondscommerce.co.uk/php/php-custom-error-and-exception-handler-make-php-stricter/ – eL-Prova Mar 13 '13 at 14:23

4 Answers4

4

You can try using http://www.xdebug.org/

AlfaTeK
  • 7,487
  • 14
  • 49
  • 90
1

If you're running out of memory while selecting data from a database, chances are you're trying to grab way too much data at once from the DB and trying to load it all into memory. Does your Database Read() method do something like automagically fetch the data and get it all into a variable for you?

You should probably consider incrementally processing the data, as an alternative to grabbing it all at once, or work with smaller datasets. On the other hand, if you have the ability to do so and you really need to process so much data at once, you could consider changing the memory limit and increasing it using ini_set('memory_limit', '256M'); to increase it to 256MB, for example.

See:

http://php.net/manual/en/ini.core.php#ini.memory-limit and http://php.net/ini_set

Edit:

For figuring out the trace of how you got to this point, Xdebug is probably your best bet as far as free solutions are concerned. I'd take a look at: http://www.xdebug.org/docs/execution_trace

The xdebug.show_mem_delta option will probably be the most beneficial to you for figuring out what's spiking your memory usage when looking at the stack traces.

Jeremy Privett
  • 4,455
  • 2
  • 32
  • 35
  • I understand the reason for that error but I don't know where it exactly occurs because Line 60 of that class is uses about 200 times inside my project. There must be some SQL statement somewhere which fetches way too much data. I need to localize it. There is nothing wrong with my DB class. – Norwald2 Feb 23 '11 at 19:35
  • Edited to add a couple specific items when using xdebug. Hope that helps. – Jeremy Privett Feb 23 '11 at 20:57
0

That's most likely exactly where the problem occurred - your script is sucking up almost all of the 128megabyte limit, and then the database class tries to allocate a bit more space to read something from the database, the limit gets crossed and the script barfs.

What are you doing that requires using 128meg of memory?

Marc B
  • 356,200
  • 43
  • 426
  • 500
  • 1
    I understand the reason for that error but I don't know where it exactly occurs because Line 60 of that class is uses about 200 times inside my project. – Norwald2 Feb 23 '11 at 19:35
  • What are you doing that requires so much memory? – Marc B Feb 23 '11 at 19:37
  • 1
    Well, I don't know. I am using a Object Relation Mapper so I don't have full manual control what is going on with the SQL Queries it generates. That's why I somehow need to trace back which SQL Statement is responsible for this error. XDebug is not an option because I am on hosted server where I am not allowed to install PHP extension. – Norwald2 Feb 23 '11 at 21:18
  • Sprinkle your code with `echo memory_get_usage()` calls, and start tracking down where usage balloons upwards. That's about all I can think of track down where it's getting sucked up. I'd focus on particular on areas where you're actually running queries, and where the date from those queries is being consumed. – Marc B Feb 24 '11 at 02:32
-1

You can try using PHP Error to get a stack trace for errors.

JL235
  • 2,455
  • 2
  • 19
  • 14
  • I don't think that will work for fatals, since `register_shutdown_function()` doesn't have access to the previous script's call stack. – Ian Dunn May 17 '22 at 16:00