Error MEM · php
Allowed memory size exhausted
A PHP script asked for more memory than your account allows, so it was killed part-way through.
Also seen as: Fatal error: Allowed memory size of N bytes exhausted · PHP out of memory · memory_limit exceeded
What it actually means
PHP gives each request a memory ceiling. When a script asks for more, PHP stops it immediately with a fatal error rather than letting it consume the whole server.
The message names the exact number and the exact line:
Fatal error: Allowed memory size of 268435456 bytes exhausted
(tried to allocate 20480 bytes) in /home/u1234/htdocs/wp-includes/functions.php on line 812
That line number is rarely the culprit. It’s simply where the last small allocation happened to fall. Something earlier consumed the memory; this line was just unlucky. Look at what the request was doing, not at the line named.
If PHP is configured to hide errors you get a blank page instead — the white screen of death is very often this error with display turned off.
Why it happens
Loading a whole result set into an array
SELECT * FROM orders into an array works fine over 500 rows and dies over 500,000. The query didn’t change; the table grew.
This is the most common cause on any site that has been running for a while.
Image processing
A 4000×3000 JPEG is a couple of megabytes on disk and roughly 48 MB in memory once decoded — width × height × 4 bytes per pixel. Resize two at once and you’re near a 256 MB ceiling before your code does anything else.
Phone photos are routinely this big, so a user upload form hits it long before your test images do.
A plugin doing too much at once
Backup, migration and image-optimisation plugins load large amounts of data in one pass. They usually work on a small site and fail as it grows.
An accidental infinite loop or recursion
A loop that appends to an array without terminating will exhaust memory quickly. If the error appeared right after a code change, look there first.
How to fix it
1. Find what actually used the memory
Log usage at a few points rather than guessing:
error_log('before import: ' . round(memory_get_usage(true) / 1048576) . ' MB');
// ... the suspect code ...
error_log('after import: ' . round(memory_get_usage(true) / 1048576) . ' MB');
error_log('peak: ' . round(memory_get_peak_usage(true) / 1048576) . ' MB');
memory_get_peak_usage() is the number that matters — it’s what PHP compares against the limit.
2. Process rows in batches instead of all at once
The fix for most memory errors is to stop holding everything in memory:
// Dies on a large table
$rows = $db->fetchAll('SELECT * FROM orders');
foreach ($rows as $row) { process($row); }
// Constant memory, any table size
$stmt = $pdo->prepare('SELECT * FROM orders');
$stmt->execute();
while ($row = $stmt->fetch(PDO::FETCH_ASSOC)) {
process($row);
}
Fetching one row at a time keeps usage flat no matter how many rows there are.
3. Free large variables as you go
PHP releases memory when nothing references a value any more, but a long-running loop can hold references longer than you expect:
foreach ($files as $file) {
$image = imagecreatefromjpeg($file);
// ... work ...
imagedestroy($image); // GD memory is not freed by unset() alone
unset($image);
}
For images specifically, imagedestroy() matters — the underlying buffer isn’t PHP-managed.
4. Raise the limit, if you genuinely need it
This is a last resort, not a first move. If the code needs 300 MB because it’s badly written, raising the limit just moves the failure.
Where it’s legitimate — a one-off import, a large legitimate dataset — try php.ini in your web root:
memory_limit = 256M
Or for WordPress, in wp-config.php above the “stop editing” line:
define('WP_MEMORY_LIMIT', '256M');
On shared hosting the account ceiling is enforced above PHP, so you cannot raise it past what your plan allows — the setting will silently cap.
5. Shrink images before processing them
If you accept uploads, resize on the way in rather than holding full-resolution files in memory later. Cap the accepted dimensions, and reject anything absurd at the door rather than trying to process it.
On CWP specifically
Free CWP accounts have a 256 MB memory ceiling per account, enforced above PHP — so raising memory_limit beyond it has no effect.
The exact fatal error, with the script and line, appears in your control panel’s Error Log. If you’re seeing a blank page instead of a message, the error is still in the log.
When this means you've outgrown free hosting
If your work genuinely needs more than 256 MB per request — large dataset processing, video, high-resolution image pipelines — that’s beyond what shared hosting allocates, and batching won’t always help.
Before upgrading, check it really is a legitimate need. In our experience most memory errors are a fetchAll() that should be a fetch() loop, and that fix costs nothing.
Related errors
-
500
500 Internal Server Error
Something in your application or server configuration crashed, and the server is deliberately withholding the detail from visitors — the real message is in your error log. -
WSOD
White screen of death
PHP hit a fatal error and error display is turned off, so the server sent an empty page instead of a message. -
TIME
Maximum execution time exceeded
A PHP script ran longer than allowed and was stopped — almost always waiting on a slow query or a slow external service. -
413
413 Payload Too Large
You tried to upload something bigger than the server accepts, and it rejected the request before reading it all.
Post the exact error and your account name on the community forum — staff and other users answer there, and the thread helps the next person who hits this.