Laravel 4.2, Amazon ec2 Linux
PHP Fatal error:
Allowed memory size of 262144 bytes exhausted (tried to allocate 3072 bytes) in /var/www/html/vendor/composer/ClassLoader.php on line 78
TL;DR You need to increase your memory_limit setting in php.ini. You're barely letting your scripts use any memory at all.
The Problem
The error message Allowed memory size of 262144... means you have a memory_limit setting of 256 kb. That is far too low. For most useful applications, you need at least a few MB. I would start with 8MB and see how it goes.
The Solution
Change the memory_limit setting. In theory, you can do this two ways: (1) edit php.ini or (2) use ini_set().
In practice, you cannot always use ini_set('memory_limit', value);. For one thing, some extensions, like suhosin, prevent scripts from setting the memory_limit in this way. For another, you have to be careful how you do it. For example, you proposed using ini_set('memory_limit', '1G');. But the shorthand (K, M, G) only works in php.ini, not in ini_set. You would have to enter an actual number of bytes (e.g., 1073741824). Also, 1G is pretty excessive for most purposes; very, very few non-malicious PHP scripts need anything like that. Even pretty heavy frameworks like WordPress typically run well within 64 MB or so, even with lots of plugins loaded up.
How to change the setting in php.ini
Figure out which php.ini file you are using (it's not uncommon to have several floating around, depending on how you installed things). You can do this in two ways:
Put this in a .php file and run it: <?php phpinfo();
On a command line, type php -i | grep php.ini. You should see a line that says something like Loaded Configuration File => /etc/php.ini (the output may vary by system, of course).
Edit the file you just found by changing the line that starts with memory_limit = to something more appropriate, like
memory_limit = 8M
Feel free to bump that number up as needed, but I would recommend starting small (not 1G) to prevent bringing your server to its knees accidentally.
One caveat: if this is a testing/development machine and you are running a debugger or profiler like xdebug, you may want to start much higher, and 1G is not insane. But don't start with such a high number on a production machine; work your way up to it.
I'm getting the error when I run my PHP script....
Fatal error: Out of memory (allocated 1827405824) (tried to allocate 88800 bytes)
I've added this line to my PHP script..
ini_set("memory_limit","3000M");
This statement does seem to correctly control the memory usage, but I dont seem to be able to get it above about 1.8GB.
Its as if the upper memory limit is being restricted somewhere else.
I've also added to the php.ini...
memory_limit = 3000M
Does anyone know if the memory is restricted elsewhere?
I'm running a local server with Xampp.
I have Windows 7, 64-bit with 4GB RAM.
My script uses PHP's GD image library and I get the error when trying to allocate an image reference with ImageCreateTrueColor().
(I know this is a huge amount of memory - but this is just a one-of script, and its just a lot easier to do it this way.)
Thanks.
Update....
#elusive #Orbling
I expect everybody's bored whith this question, but here is the simplified code which illustrates the problem.
<?php
ini_set("memory_limit","4000000000");
echo "ini_get = " . ini_get('memory_limit') . "<br>\n";
echo "memory_get_usage = " . memory_get_usage(true) . "<br>\n";
$bigImageHandle = imagecreatetruecolor(22200, 24800); //this is line 5
?>
Browser output...
ini_get = 4000000000
memory_get_usage = 524288
Fatal error: Out of memory (allocated 1843396608) (tried to allocate 88800 bytes) in
E:\User\My_Webs\experiments\houseshunting\temp\osMaps\t1.php on line 5
I tested this out with a smaller set of tiles and the memory used by imagecreatetruecolor() and I estimate I need 2.7GB
Using Acquia Dev Desktop, I had many memory limit crashes.
After having increased the memory limit into PHP.ini.
php_value memory_limit 1024M
php_value max_execution_time 3000
This issue was less frequent but still occuring ( Especially with Feature Recreate )
Into my httpd.conf I increased the StackThread to 16M
ThreadStackSize 16*1024*1024
And it solved the memory crash issue.
Hope it can help
You're running on a 64-bit operating system, but Apache and PHP are likely still 32-bit. If you're using mod_php, apache would be the limiting factor here.
32-bit processes are limited about 2GiB of RAM unless you used the /3GB switch and the software is aware of 3GB support.
That still leaves up about 200 MiB that seems unused, but its small enough that it can be used by various libraries that all have to be loaded in memory
As far as I know, the library usage won't show up in the committed memory, but still counts towards the 2GiB limit (much like device memory counts towards the 4GiB limit on 32-bit windows. Where installing 2 GiB graphics card brings you down to under 2GiB of usable RAM).
Most likely solution? Install a 64-bit PHP, and then dispatch it to that (using a system() call, perhaps)
In Ubuntu 18.04
Check version PHP: php -v
In my case I have PHP 7.4
Edit file: nano /etc/php/7.4/apache2/php.ini
Search and change memory_limit = 2048M
Edit file: nano /etc/php/7.4/cli/php.ini
Search and change memory_limit = 2048M
Finally: systemctl restart apache2
Which PHP version are you using?
The memory_limit variable is, or was, contained in a 32-bit integer, so can not go above 2GB.
See: http://bugs.php.net/bug.php?id=39132&edit=1
From the bottom comment on that bug report, it might be the routine that translates the human readable form to a number, try putting it in digits.
Check your Apache config (e.g., httpd.conf). There's likely an RLimitMEM directive limiting the memory allow for children processes handling requests.
So, you can set your PHP limit all you want, if Apache spawns the process with a memory limit, you can't exceed that.
If you're on a hosted service and have a shared server, likely you don't have access to this config and need to work with your provider. As you can see, it's configuration that applies server-wide... you're not likely going to get them to change this. Then again, if you're looking to spawn bigger than 1.5Gig processes, you prolly should be either solving the problem a different way (others have suggested this) or getting a dedicated server of some kind (e.g. EC2).
For example:
/usr/local/apache/conf
#RLimitMEM 85643200 104857600 # Limit to: 80Mb / process, 100Mb total
RLimitMEM 134217728 537395200 # Limit to: 128Mb / Process, 512Mb total
The issue is likely to be caused by running 32-bit apache and php. Try upgrading these to 64-bit binaries and see if that fixes the issue.
I've had exactly the same problem and after searching a lot I discovered it had nothing to do wih memory limit but with a bug in my code: I had a function using an array, located in external file. In this function I had set the array as "global" but missed to include the file with tis array....
Like the spiderplant0's error, this was giving me an error with a very very huge memory allocation.
So check your code and try to see which part create this error.
Try this
set_time_limit(300);
ini_set('memory_limit', '20000M');
Try this:
#php_value memory_limit 300M
#php_value upload_max_filesize 200M
#php_value post_max_size 200M
#php_value max_execution_time 80000
#php_value max_input_time 80000
try ini_set('memory_limit', '-1');
I'm getting the error when I run my PHP script....
Fatal error: Out of memory (allocated 1827405824) (tried to allocate 88800 bytes)
I've added this line to my PHP script..
ini_set("memory_limit","3000M");
This statement does seem to correctly control the memory usage, but I dont seem to be able to get it above about 1.8GB.
Its as if the upper memory limit is being restricted somewhere else.
I've also added to the php.ini...
memory_limit = 3000M
Does anyone know if the memory is restricted elsewhere?
I'm running a local server with Xampp.
I have Windows 7, 64-bit with 4GB RAM.
My script uses PHP's GD image library and I get the error when trying to allocate an image reference with ImageCreateTrueColor().
(I know this is a huge amount of memory - but this is just a one-of script, and its just a lot easier to do it this way.)
Thanks.
Update....
#elusive #Orbling
I expect everybody's bored whith this question, but here is the simplified code which illustrates the problem.
<?php
ini_set("memory_limit","4000000000");
echo "ini_get = " . ini_get('memory_limit') . "<br>\n";
echo "memory_get_usage = " . memory_get_usage(true) . "<br>\n";
$bigImageHandle = imagecreatetruecolor(22200, 24800); //this is line 5
?>
Browser output...
ini_get = 4000000000
memory_get_usage = 524288
Fatal error: Out of memory (allocated 1843396608) (tried to allocate 88800 bytes) in
E:\User\My_Webs\experiments\houseshunting\temp\osMaps\t1.php on line 5
I tested this out with a smaller set of tiles and the memory used by imagecreatetruecolor() and I estimate I need 2.7GB
Using Acquia Dev Desktop, I had many memory limit crashes.
After having increased the memory limit into PHP.ini.
php_value memory_limit 1024M
php_value max_execution_time 3000
This issue was less frequent but still occuring ( Especially with Feature Recreate )
Into my httpd.conf I increased the StackThread to 16M
ThreadStackSize 16*1024*1024
And it solved the memory crash issue.
Hope it can help
You're running on a 64-bit operating system, but Apache and PHP are likely still 32-bit. If you're using mod_php, apache would be the limiting factor here.
32-bit processes are limited about 2GiB of RAM unless you used the /3GB switch and the software is aware of 3GB support.
That still leaves up about 200 MiB that seems unused, but its small enough that it can be used by various libraries that all have to be loaded in memory
As far as I know, the library usage won't show up in the committed memory, but still counts towards the 2GiB limit (much like device memory counts towards the 4GiB limit on 32-bit windows. Where installing 2 GiB graphics card brings you down to under 2GiB of usable RAM).
Most likely solution? Install a 64-bit PHP, and then dispatch it to that (using a system() call, perhaps)
In Ubuntu 18.04
Check version PHP: php -v
In my case I have PHP 7.4
Edit file: nano /etc/php/7.4/apache2/php.ini
Search and change memory_limit = 2048M
Edit file: nano /etc/php/7.4/cli/php.ini
Search and change memory_limit = 2048M
Finally: systemctl restart apache2
Which PHP version are you using?
The memory_limit variable is, or was, contained in a 32-bit integer, so can not go above 2GB.
See: http://bugs.php.net/bug.php?id=39132&edit=1
From the bottom comment on that bug report, it might be the routine that translates the human readable form to a number, try putting it in digits.
Check your Apache config (e.g., httpd.conf). There's likely an RLimitMEM directive limiting the memory allow for children processes handling requests.
So, you can set your PHP limit all you want, if Apache spawns the process with a memory limit, you can't exceed that.
If you're on a hosted service and have a shared server, likely you don't have access to this config and need to work with your provider. As you can see, it's configuration that applies server-wide... you're not likely going to get them to change this. Then again, if you're looking to spawn bigger than 1.5Gig processes, you prolly should be either solving the problem a different way (others have suggested this) or getting a dedicated server of some kind (e.g. EC2).
For example:
/usr/local/apache/conf
#RLimitMEM 85643200 104857600 # Limit to: 80Mb / process, 100Mb total
RLimitMEM 134217728 537395200 # Limit to: 128Mb / Process, 512Mb total
The issue is likely to be caused by running 32-bit apache and php. Try upgrading these to 64-bit binaries and see if that fixes the issue.
I've had exactly the same problem and after searching a lot I discovered it had nothing to do wih memory limit but with a bug in my code: I had a function using an array, located in external file. In this function I had set the array as "global" but missed to include the file with tis array....
Like the spiderplant0's error, this was giving me an error with a very very huge memory allocation.
So check your code and try to see which part create this error.
Try this
set_time_limit(300);
ini_set('memory_limit', '20000M');
Try this:
#php_value memory_limit 300M
#php_value upload_max_filesize 200M
#php_value post_max_size 200M
#php_value max_execution_time 80000
#php_value max_input_time 80000
try ini_set('memory_limit', '-1');
I just scaffolded a new module and when I save using the generated form I get:
Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to allocate 19456 bytes) in /Applications/MAMP/htdocs/ats/lib/vendor/symfony/lib/plugins/sfDoctrinePlugin/lib/vendor/doctrine/Doctrine/Hydrator/Graph.php on line 404
Any ideas why?
symfony is quite greedy for memory, so this sometimes happens. You can increase the memory available to PHP/symfony via php.ini as suggested above:
php.ini:
memory_limit = 128M
128M here is just an example, but one which you might need to evaluate.
because that's the configured memory limit of your php. you may want to find what php.ini it uses from phpinfo() and edit it to give symfony more memory.
The memory_limit is the maximum amount of memory a PHP script is allowed to use. Basically, this is a security configuration option, to ensure you don't have a PHP script that does mad and consumes all the memory of the server -- or worse, that you don't have several PHP script that eat more memory than the server has.
This configuration directive can be set in the php.ini file ; it's the file that sets the configuration of PHP.
To find out where the php.ini file is on your server, you can use the phpinfo() function : somewhere near the top of the output, there should be a "Loaded Configuration File" option.
Which value should be used for memory_limit is an interesting question... In the past, when we were only writting small script, 8MB was generally enough.
Now, with Frameworks, bigger applications structured in layers, ORM, and all that, 8MB is generally not enough (as you obviously noticed) -- I generally set memory_limit to 32M on my production servers, which is almost always enough for my applications, without being too much.
So, in my php.ini file, I have :
memory_limit = 32M
Note : it would be tempting to put a very high value for memory_limit, to just get rid of the problem... But remember that memory_limit is here as a security : you should make sure your server has enough memory to answer several requests at the same time !
I have a bunch of client point of sale (POS) systems that periodically send new sales data to one centralized database, which stores the data into one big database for report generation.
The client POS is based on PHPPOS, and I have implemented a module that uses the standard XML-RPC library to send sales data to the service. The server system is built on CodeIgniter, and uses the XML-RPC and XML-RPCS libraries for the webservice component. Whenever I send a lot of sales data (as little as 50 rows from the sales table, and individual rows from sales_items pertaining to each item within the sale) I get the following error:
Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 54 bytes)
128M is the default value in php.ini, but I assume that is a huge number to break. In fact, I have even tried setting this value to 1024M, and all it does is take a longer time to error out.
As for steps I've taken, I've tried disabling all processing on the server-side, and have rigged it to return a canned response regardless of the input. However, I believe the problem lies in the actual sending of the data. I've even tried disabling the maximum script execution time for PHP, and it still errors out.
Changing the memory_limit by ini_set('memory_limit', '-1'); is not a proper solution. Please don't do that.
Your PHP code may have a memory leak somewhere and you are telling the server to just use all the memory that it wants. You wouldn't have fixed the problem at all. If you monitor your server, you will see that it is now probably using up most of the RAM and even swapping to disk.
You should probably try to track down the offending code in your code and fix it.
ini_set('memory_limit', '-1'); overrides the default PHP memory limit.
The correct way is to edit your php.ini file.
Edit memory_limit to your desire value.
As from your question, 128M (which is the default limit) has been exceeded, so there is something seriously wrong with your code as it should not take that much.
If you know why it takes that much and you want to allow it set memory_limit = 512M or higher and you should be good.
The memory allocation for PHP can be adjusted permanently, or temporarily.
Permanently
You can permanently change the PHP memory allocation two ways.
If you have access to your php.ini file, you can edit the value for memory_limit to your desire value.
If you do not have access to your php.ini file (and your webhost allows it), you can override the memory allocation through your .htaccess file. Add php_value memory_limit 128M (or whatever your desired allocation is).
Temporary
You can adjust the memory allocation on the fly from within a PHP file. You simply have the code ini_set('memory_limit', '128M'); (or whatever your desired allocation is). You can remove the memory limit (although machine or instance limits may still apply) by setting the value to "-1".
It's very easy to get memory leaks in a PHP script - especially if you use abstraction, such as an ORM. Try using Xdebug to profile your script and find out where all that memory went.
When adding 22.5 million records into an array with array_push I kept getting "memory exhausted" fatal errors at around 20M records using 4G as the memory limit in file php.ini. To fix this, I added the statement
$old = ini_set('memory_limit', '8192M');
at the top of the file. Now everything is working fine. I do not know if PHP has a memory leak. That is not my job, nor do I care. I just have to get my job done, and this worked.
The program is very simple:
$fh = fopen($myfile);
while (!feof($fh)) {
array_push($file, stripslashes(fgets($fh)));
}
fclose($fh);
The fatal error points to line 3 until I boosted the memory limit, which
eliminated the error.
I kept getting this error, even with memory_limit set in php.ini, and the value reading out correctly with phpinfo().
By changing it from this:
memory_limit=4G
To this:
memory_limit=4096M
This rectified the problem in PHP 7.
You can properly fix this by changing memory_limit on fastcgi/fpm:
$vim /etc/php5/fpm/php.ini
Change memory, like from 128 to 512, see below
; Maximum amount of memory a script may consume (128 MB)
; http://php.net/memory-limit
memory_limit = 128M
to
; Maximum amount of memory a script may consume (128 MB)
; http://php.net/memory-limit
memory_limit = 512M
When you see the above error - especially if the (tried to allocate __ bytes) is a low value, that could be an indicator of an infinite loop, like a function that calls itself with no way out:
function exhaustYourBytes()
{
return exhaustYourBytes();
}
Your site's root directory:
ini_set('memory_limit', '1024M');
After enabling these two lines, it started working:
; Determines the size of the realpath cache to be used by PHP. This value should
; be increased on systems where PHP opens many files to reflect the quantity of
; the file operations performed.
; http://php.net/realpath-cache-size
realpath_cache_size = 16k
; Duration of time, in seconds for which to cache realpath information for a given
; file or directory. For systems with rarely changing files, consider increasing this
; value.
; http://php.net/realpath-cache-ttl
realpath_cache_ttl = 120
Rather than changing the memory_limit value in your php.ini file, if there's a part of your code that could use a lot of memory, you could remove the memory_limit before that section runs, and then replace it after.
$limit = ini_get('memory_limit');
ini_set('memory_limit', -1);
// ... do heavy stuff
ini_set('memory_limit', $limit);
In Drupal 7, you can modify the memory limit in the settings.php file located in your sites/default folder. Around line 260, you'll see this:
ini_set('memory_limit', '128M');
Even if your php.ini settings are high enough, you won't be able to consume more than 128 MB if this isn't set in your Drupal settings.php file.
Change the memory limit in the php.ini file and restart Apache. After the restart, run the phpinfo(); function from any PHP file for a memory_limit change confirmation.
memory_limit = -1
Memory limit -1 means there is no memory limit set. It's now at the maximum.
Just add a ini_set('memory_limit', '-1'); line at the top of your web page.
And you can set your memory as per your need in the place of -1, to 16M, etc..
For Drupal users, this Chris Lane's answer of:
ini_set('memory_limit', '-1');
works but we need to put it just after the opening
<?php
tag in the index.php file in your site's root directory.
PHP 5.3+ allows you to change the memory limit by placing a .user.ini file in the public_html folder.
Simply create the above file and type the following line in it:
memory_limit = 64M
Some cPanel hosts only accept this method.
Crash page?
(It happens when MySQL has to query large rows. By default, memory_limit is set to small, which was safer for the hardware.)
You can check your system existing memory status, before increasing php.ini:
# free -m
total used free shared buffers cached
Mem: 64457 63791 666 0 1118 18273
-/+ buffers/cache: 44398 20058
Swap: 1021 0 1021
Here I have increased it as in the following and then do service httpd restart to fix the crash page issue.
# grep memory_limit /etc/php.ini
memory_limit = 512M
For those who are scratching their heads to find out why on earth this little function should cause a memory leak, sometimes by a little mistake, a function starts recursively call itself for ever.
For example, a proxy class that has the same name for a function of the object that is going to proxy it.
class Proxy {
private $actualObject;
public function doSomething() {
return $this->actualObjec->doSomething();
}
}
Sometimes you may forget to bring that little actualObjec member and because the proxy actually has that doSomething method, PHP wouldn't give you any error and for a large class, it could be hidden from the eyes for a couple of minutes to find out why it is leaking the memory.
I had the error below while running on a dataset smaller than had worked previously.
Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 4096 bytes) in C:\workspace\image_management.php on line 173
As the search for the fault brought me here, I thought I'd mention that it's not always the technical solutions in previous answers, but something more simple. In my case it was Firefox. Before I ran the program it was already using 1,157 MB.
It turns out that I'd been watching a 50 minute video a bit at a time over a period of days and that messed things up. It's the sort of fix that experts correct without even thinking about it, but for the likes of me it's worth bearing in mind.
In my case on mac (Catalina - Xampp) there was no loaded file so I had to do this first.
sudo cp /etc/php.ini.default /etc/php.ini
sudo nano /etc/php.ini
Then change memory_limit = 512M
Then Restart Apache and check if file loaded
php -i | grep php.ini
Result was
Configuration File (php.ini) Path => /etc
Loaded Configuration File => /etc/php.ini
Finally Check
php -r "echo ini_get('memory_limit').PHP_EOL;"
Using yield might be a solution as well. See Generator syntax.
Instead of changing the PHP.ini file for a bigger memory storage, sometimes implementing a yield inside a loop might fix the issue. What yield does is instead of dumping all the data at once, it reads it one by one, saving a lot of memory usage.
The reason for this error is that your server configuration has a very low memory limit. Try adding this to wp-config.php (put it after <?php in this file):
define('WP_MEMORY_LIMIT', '96M');
Please note that this limit is OK for the theme and the plugins that come with the theme. If you want to enable other plugins you may need to increase the limit further.
define('WP_MEMORY_LIMIT', '256M');
Running the script like this (cron case for example): php5 /pathToScript/info.php produces the same error.
The correct way: php5 -cli /pathToScript/info.php
If you're running a WHM-powered VPS (virtual private server) you may find that you do not have permissions to edit PHP.INI directly; the system must do it. In the WHM host control panel, go to Service Configuration → PHP Configuration Editor and modify memory_limit:
I find it useful when including or requiring _dbconnection.php_ and _functions.php in files that are actually processed, rather than including in the header. Which is included in itself.
So if your header and footer is included, simply include all your functional files before the header is included.
Greetings is a very common problem because if you have very little memory allocated to php and your website is growing will require more resources.
I found myself in a site that had problems that gave error 500 to modify only some products, the problem was that they had used very heavy images in those specific products, solution:
1.- Increase "memory_limit" in php.ini
2.- Lower the weight of the images.
3.- Adapt again "memory_limit" to an acceptable value "512M" at least for me more than enough.
now it is important that you verify that the changes are being made because php apart from having several versions and several types of installations on the server, maybe you modify one and it does not work and this is because you are not modifying the correct php.ini file.
How do you verify that you are modifying the correct file?
In the prestashop dashboard go to advanced settings/information there you can see "Memory limit".
always remember that after making a change in the php.ini file it is advisable to restart apache or Nginx.
Ubuntu: sudo services apache2 restart
IMPORTANT NOTE: Never set the "memory_limit = -1" as many people mention here. The problem is that if you have a problem with a file or module you could be in a continuous loop consuming all the server's memory and processor. Let's take a simple example: a module has an error and makes a call to a function and until it is not positive it keeps calling, this will create an infinite loop and it will never stop doing it because php has no limit.
I hope it helps colleagues who have this problem.
The most common cause of this error message for me is omitting the "++" operator from a PHP "for" statement. This causes the loop to continue forever, no matter how much memory you allow to be used. It is a simple syntax error, yet is difficult for the compiler or runtime system to detect. It is easy for us to correct if we think to look for it!
But suppose you want a general procedure for stopping such a loop early and reporting the error? You can simply instrument each of your loops (or at least the innermost loops) as discussed below.
In some cases such as recursion inside exceptions, set_time_limit fails, and the browser keeps trying to load the PHP output, either with an infinite loop or with the fatal error message which is the topic of this question.
By reducing the allowed allocation size near the beginning of your code you might be able to prevent the fatal error, as discussed in the other answers.
Then you may be left with a program that terminates, but is still difficult to debug.
Whether or not your program terminates, instrument your code by inserting BreakLoop() calls inside your program to gain control and find out what loop or recursion in your program is causing the problem.
The definition of BreakLoop is as follows:
function BreakLoop($MaxRepetitions=500,$LoopSite="unspecified")
{
static $Sites=[];
if (!#$Sites[$LoopSite] || !$MaxRepetitions)
$Sites[$LoopSite]=['n'=>0, 'if'=>0];
if (!$MaxRepetitions)
return;
if (++$Sites[$LoopSite]['n'] >= $MaxRepetitions)
{
$S=debug_backtrace(); // array_reverse
$info=$S[0];
$File=$info['file'];
$Line=$info['line'];
exit("*** Loop for site $LoopSite was interrupted after $MaxRepetitions repetitions. In file $File at line $Line.");
}
} // BreakLoop
The $LoopSite argument can be the name of a function in your code. It isn't really necessary, since the error message you will get will point you to the line containing the BreakLoop() call.
In my case it was a brief issue with the way a function was written. A memory leak can be caused by assigning a new value to a function's input variable, e.g.:
/**
* Memory leak function that illustrates unintentional bad code
* #param $variable - input function that will be assigned a new value
* #return null
**/
function doSomehting($variable){
$variable = 'set value';
// Or
$variable .= 'set value';
}
Increasing the memory_limit fixed the problem. However, I had problems finding the memory limit. I am working on my project directly from live server, so if you're doing the same, on cPanel you can find the memory_limit if you go to Software - MultiPHP INI Editor and select the location. I increased mine from 256M to 512M. You can also find instructions here.