jpg uploads cause large file to be added to root with name core.XXXXXX
Permalink
Since updating to 5.6.3.1 to get over the multiple file upload bug, I have noticed that whenever a jpg is uploaded to the site via the file manager a file gets written to the root of the server that is approximately 50MB when the uploaded file was only 300KB. This is quickly exhausting the limits of the account and I have to keep deleting these files from the root so that the clients site doesn't crash. All the files are written as core.XXXXXX
Any suggestions? The client uses MAC and I am using PC and the result is the same... although PDFs seem to upload without the same issue.
Any suggestions? The client uses MAC and I am using PC and the result is the same... although PDFs seem to upload without the same issue.
core files are nothing but memory dumps created when a PHP process crashes. PHP shouldn't crash just because a file is too big, it usually hits the memory limit first. I'd start digging around the server logs to get more information about it. Not much we can do from the concrete5 side..
Hi Remo
Thanks for the tip about what these files mean. I am still puzzled though as I run a VPS server and this houses approx 30 C5 sites. I have only been getting this core.xxx file on sites that are either 5.6.3 or 5.6.3.1. I just now went to 5 sites and uploaded the same jpg to the file manager, got the core.xxx dump on 2 sites and the other 3 nothing happened? The file was about 300KB which is not big and the C5 GUI said they were successful uploads. No errors in C5 or error logs on each website.. I am very confused about how to see what the issue is without some type of error or log of error. I am no expert at server stuff so would greatly appreciate a hand on how I could see what the dump was caused from? apart from an image upload... which seems to be the trigger.
Thanks for the tip about what these files mean. I am still puzzled though as I run a VPS server and this houses approx 30 C5 sites. I have only been getting this core.xxx file on sites that are either 5.6.3 or 5.6.3.1. I just now went to 5 sites and uploaded the same jpg to the file manager, got the core.xxx dump on 2 sites and the other 3 nothing happened? The file was about 300KB which is not big and the C5 GUI said they were successful uploads. No errors in C5 or error logs on each website.. I am very confused about how to see what the issue is without some type of error or log of error. I am no expert at server stuff so would greatly appreciate a hand on how I could see what the dump was caused from? apart from an image upload... which seems to be the trigger.
Don't get me wrong, I'm not saying concrete5 doesn't cause the problem. It's possible that there's a code which causes PHP to crash. However, as PHP is a scripting language, it should never crash, it should report problems properly. It's still possible that there's something fishy with concrete5.
The problem is just, that you have to get more information in order to figure it out.
Analyzing those core dump files isn't the easiest thing to do, it's certainly not something I can guide you through that easily. Especially since I'm also not the expert in this field. I do understand the basics and know how things are working together, but I'd have to google around myself.
You can try to call gdb /usr/bin/php core-dump-file to get more insight and continue from there, but that might be a long journey..
It could be easier to simply upgrade PHP and see if it still happens.
The problem is just, that you have to get more information in order to figure it out.
Analyzing those core dump files isn't the easiest thing to do, it's certainly not something I can guide you through that easily. Especially since I'm also not the expert in this field. I do understand the basics and know how things are working together, but I'd have to google around myself.
You can try to call gdb /usr/bin/php core-dump-file to get more insight and continue from there, but that might be a long journey..
It could be easier to simply upgrade PHP and see if it still happens.
Hi Remo
I did an experiment and took one of my dev sites 5.6.2.1 and uploaded some images with no core dumps. Then upgraded the site to 5.6.3 and immediately got the core file dumps when I uploaded an 11KB image!!! I have the memory limit set on my VPS server to 96M so went all the way up to 256M and still got the core dump files... so I downgraded the site again to 5.6.2.1 and they core dump files no longer happen. OK so it is obvious it is from the upgrade by I am also aware it just might be my environment that is not compatible any more. PHP version being 5.2.17 - is there more recent versions?. Not being a programmer or server expert is this gdb call something I can ask my server managers to do for me?
I did an experiment and took one of my dev sites 5.6.2.1 and uploaded some images with no core dumps. Then upgraded the site to 5.6.3 and immediately got the core file dumps when I uploaded an 11KB image!!! I have the memory limit set on my VPS server to 96M so went all the way up to 256M and still got the core dump files... so I downgraded the site again to 5.6.2.1 and they core dump files no longer happen. OK so it is obvious it is from the upgrade by I am also aware it just might be my environment that is not compatible any more. PHP version being 5.2.17 - is there more recent versions?. Not being a programmer or server expert is this gdb call something I can ask my server managers to do for me?
My server guys said they can go to either php version 5.3.28 or 5.4.27 - should I only go slow and do 5.3.28 first?
Personally i'd rip off the bandaid and go to 5.4... honestly there weren't many "breaking changes" from 5.3 to 5.4 unless you had some bad programming practices.
http://www.php.net/manual/en/migration54.incompatible.php...
Also, here's a list of closed bug reports with the GD library in php 5.2. Good chance that one of them could have been causing your issue.
https://bugs.php.net/search.php?search_for=&boolean=0&limit=...
http://www.php.net/manual/en/migration54.incompatible.php...
Also, here's a list of closed bug reports with the GD library in php 5.2. Good chance that one of them could have been causing your issue.
https://bugs.php.net/search.php?search_for=&boolean=0&limit=...
Hi
My server guys came back with the following;
We have checked the core file through gdb and it was generated due to the following :
-----------------
Core was generated by `/usr/bin/php /home/jgdev1/public_html/tg/index.php'.
Program terminated with signal SIGSEGV, Segmentation fault.
-----------------
The possible reason for the core files getting generated is when a php process is killed, apache creates core files under the account. So you are requested to go through the application installed and upgrade it to the latest version if required.
My server guys came back with the following;
We have checked the core file through gdb and it was generated due to the following :
-----------------
Core was generated by `/usr/bin/php /home/jgdev1/public_html/tg/index.php'.
Program terminated with signal SIGSEGV, Segmentation fault.
-----------------
The possible reason for the core files getting generated is when a php process is killed, apache creates core files under the account. So you are requested to go through the application installed and upgrade it to the latest version if required.
That's always the most popular answer a server guy will give you. It's them, not us.. A SIGSEGV says as much as it crashes, this doesn't help.
If you could simply kill a PHP process with a PHP script, it might even pose a security problem as one could potentially inject some code. Remember the heartbleed thing?
If it's easy to reproduce, you can try to create a test script which does the same as the upload process does. Run it, if it crashes where the problems occurs. Remove some lines, run it again.. Over and over till you know the line causing the problem. Tedious I know, but with so little information, this is the only thing you can do. At least if you don't want to upgrade PHP. 5.2 is pretty old by the way, I'd update it anyway, even if there's no problem.
If you could simply kill a PHP process with a PHP script, it might even pose a security problem as one could potentially inject some code. Remember the heartbleed thing?
If it's easy to reproduce, you can try to create a test script which does the same as the upload process does. Run it, if it crashes where the problems occurs. Remove some lines, run it again.. Over and over till you know the line causing the problem. Tedious I know, but with so little information, this is the only thing you can do. At least if you don't want to upgrade PHP. 5.2 is pretty old by the way, I'd update it anyway, even if there's no problem.
The good news is upgrading to php 5.4.27 has solved the core.xxxx dumps. The bad news is I have some sites completely not work now.. mainly ones that were not using the latest version of C5. One using 5.5.2.1 just now shows errors all over the home page... is there a way to upgrade once it is in this state??
Strict Standards: Non-static method Loader::database() should not be called statically in /home/waterm/public_html/concrete/dispatcher.php on line 23
etc etc
Strict Standards: Non-static method Loader::database() should not be called statically in /home/waterm/public_html/concrete/dispatcher.php on line 23
etc etc
That's one thing concrete5 doesn't do nicely. It causes a lot of warnings and similar things. However, you can easily hide them, either by turning them off in the debug settings in the dashboard (search for debug in the search box), or completely display them in your php.ini - if you have access to error_reporting there.
But how can I bypass all the errors... I can't seem to login
http://www.watermatic.com.au/
do I have to got via the database to switch this debug setting off
http://www.watermatic.com.au/
do I have to got via the database to switch this debug setting off
why not? The login form is there?http://www.watermatic.com.au/index.php/login/...
You can also try to edit the "Config" table with phpMyAdmin and set SITE_DEBUG_LEVEL to 0
You can also try to edit the "Config" table with phpMyAdmin and set SITE_DEBUG_LEVEL to 0
yep, found the config file in db set to 0, has made no difference to output. Yep, found the login form.. doesn't seem to accept my login details.. tried admin and superadmin.. lost now.
open index.php and put these lines in:
should look something like this afterwards:
in case login doesn't work, try to reset the admin password. Just in case..
ini_set('display_errors', 'Off'); error_reporting(0);
should look something like this afterwards:
<?php ini_set('display_errors', 'Off'); error_reporting(0); require('concrete/dispatcher.php');
in case login doesn't work, try to reset the admin password. Just in case..
added.. but doesn't seem to have stopped the errors from showing
Maybe you're not allowed to override PHP error settings.. I think you might need someone who understands PHP and your server...
Thanks for trying - will see if server guys can help
OK.. I took the site through upgrading manually and all is OK now... thanks
OK.. did some more looking and creating a php.ini at root with the following got rid of all the errors on another older c5 site
error_reporting = E_ALL & ~E_STRICT & ~E_DEPRECATED
display_errors = Off
log_errors = Off
error_reporting = E_ALL & ~E_STRICT & ~E_DEPRECATED
display_errors = Off
log_errors = Off
that's supposed to have the same effect like the PHP code I've added above. Strange..
