Editing (v7+)

 

frz replied on Apr 26, 2009 at 1:46 pm Permalink Reply

this sounds really wrong and not at all what concrete5 is supposed to be doing.

jeffc replied on Apr 26, 2009 at 1:58 pm Permalink Reply 1 Attachment

Here's a screenshot of (some of) these files. I'm very reluctant to move this to the production server until I know where these files are coming from.

masade replied on Jun 14, 2009 at 7:59 pm Permalink Reply

I am a nerd and dont know anything about servers and all.. but am too facing the same issue.. my server script has 40 files of 20gb

please help me.. what can i do to clean it up?

andrew replied on Apr 26, 2009 at 2:04 pm Permalink Reply

This charmingly named occurrence happens when some program terminates unexpectedly in linux. Something about your server's setup is unhappy with concrete5. It's really hard to say what - but when loading concrete5 up it looks like it is crashing, hard.

When this happens in linux the state of the memory is written to a file where the file is named core.PROCESSID.

http://en.wikipedia.org/wiki/Core_dump...

jeffc replied on Apr 26, 2009 at 2:10 pm Permalink Reply

Thanks Andrew. I'll check with my host to see what they can dig up from our log files.

This was also with the previous version of C5, so I'm trying out the latest release to see what happens.

marxion replied on Apr 26, 2009 at 5:18 pm Permalink Reply

I've had the same thing occurring with each release of C5 including 5.3. The files avg 21meg. I typically delete them weekly. I use Hostgator as a provider and have been meaning to research this issue.

Remo replied on Apr 27, 2009 at 2:50 am Permalink Reply

Use "gdb" do analyze these files.. I doubt that the error is in concrete5. There's probably a php script that causes the problem but a php application like concrete5 is unlikely to cause these problems...

You'll see what's wrong when you use gdb!

katz515 replied on Apr 27, 2009 at 3:07 am Permalink Reply

BTW, Happy Birthday~~ Remo~~~!

jeffc replied on Apr 27, 2009 at 3:30 pm Permalink Reply

I took a look at the core dump files as Remo suggested (thanks, by the way). The issue is the result of a seg fault from the index.php file in the C5 installation folder:

----
(gdb) core-file core.459
Core was generated by `/usr/bin/php /home/voltme/public_html/dev/wright/index.php'.
Program terminated with signal 11, Segmentation fault.
#0 0x00000000006b3be7 in ?? ()
(gdb)
----

I've seen this on two different hosts now, one running PHP 5.2.8 and the other running PHP 5.2.9.

Remo replied on Apr 27, 2009 at 4:14 pm Permalink Reply

Are you working with an apache mod? cgi? fast-cgi?

Usually it's not the php script that crashes but rather the php interpreter. The php script might do something that causes the php executable to crash but in that case there's also a problem in php (or some of its libraries)

Finding that kind of problems can be quite complicated.

I'd probably start trying different configurations and after that I'd use valgrind... Can be fun but also very annoying /-:

Sorry, don't have a better answer to that!

jeffc replied on Apr 27, 2009 at 4:33 pm Permalink Reply

I'm fairly certain neither server is running fast-cgi, but I'll double check. I don't have direct control over the server config so I'll pass this along to the hosts and see what they come up with.
Thanks again for the info.

TravisN replied on Jun 14, 2009 at 9:30 pm Permalink Reply

It's been while now, but I remember experiencing something similar when I started using concrete. From memory I increased my resource limits in php.ini. Does this help?

;;;;;;;;;;;;;;;;;;;
; Resource Limits ;
;;;;;;;;;;;;;;;;;;;
max_execution_time = 120
max_input_time = 120
memory_limit = 64M