core.##### files?

- we are having a problem with modx
- core files that are about 40 MB each keep popping up in the main directory
- the error log says:

PHP Warning: Invalid argument supplied for
foreach() in
/home/username/public_html/manager/includes/document.parser.class.inc.php
on line 810

- when we disable the cache files, there are no more core files, but the
site does not load (it’s just a white page)

Server info:
OS is Linux. I think it’s CentOS.
Kernel Version: 2.6.9-42.ELsmp
Apache Version: 1.3.37 (Unix)
PHP Version: 4.4.3
MySQL Version: 4.1.21-standard

What are core.##### files? MODx does not generate or use any of these (not that I’m aware of, anyway).

they’re just these files called core.#### (like core.1372, core.28473, etc.). according to our host, they’re being generated by the cms.

Quote from: grelca at Sep 17, 2006, 11:13 AM

they’re just these files called core.#### (like core.1372, core.28473, etc.). according to our host, they’re being generated by the cms.

First of all what release of MODx are you using?

Second, these core files sound like core dump files being produced by the operating system. They are not produced my MODx for sure. It’s possible they have something configured to debug the Apache or PHP processes that are running, which produces the core dump file for reference. You need to discuss this with your hosting provider, as this is completely dependent on the configuration of the server.

We are using MODx 0.9.2.1. Yesterday we tried overwriting all of the files with fresh ones and it still happens.

Our host said that the only part of the site that is causing PHP to crash and the subsequent core dumps is MODx. They said that there is something that causes MODx to crash the PHP and then do the core dumps.

When we disable the cache files in assets/cache, the core errors stop. However, I think this is just because the CMS is being disabled when this happens?

What could possibly cause MODx to do this?

I understand what is being claimed, however, I run a lot of MODx sites on a lot of different servers and have never seen this occur with any of my sites. The only thing that I can think of that could possibly be causing the core dump is a snippet call or other add-on being eval’d that is using a PHP statement incompatible with the version of PHP being used, or it could even be a PHP problem with the particular configuration being used there. Most likely that is the issue, either the version of PHP and MySQL don’t get along, or something else is slightly askew in the PHP configuration.

And what do you mean by disabling the cache files? You mean making it so MODx cannot write the cache files to the directory?

Finally, is this server running PHP as an Apache module, or via a FastCGI/phpSuExec approach? I’ve found lots of reports in the PHP bugs database with PHP 4.4.x versions in combination with either CentOS or MySQL 5.0.x versions, though most of them are marked bogus as they ended up being configuration/compilation issues when preparing PHP for the platform.

The snippets is a good idea - we’ll check those out, but I don’t think they are the problem. By disabling the cache files, we just make it .phps. This is what our host said:

> Finally, is this server running PHP as an Apache module, or via a
> FastCGI/phpSuExec approach? I’ve found lots of reports in the PHP bugs

cgi, phpsuexec.

> database with PHP 4.4.x versions in combination with either CentOS or
> MySQL 5.0.x versions, though most of them are marked bogus as they ended
> up being configuration/compilation issues when preparing PHP for the
> platform."

We run:

MySQL 4.1.x
PHP 4.4.3

For grins, I’d try installing the latest beta release. It’s got a LOT of bugfixes in it, and might just fix the problems. { Insert standard backup everything twice or three times disclaimer here. }

Is the beta secure/stable enough for a large scale site? We get a good amount of traffic and are concerned about the resource usage

ALSO ask how big the siteCache.idx.php file should be. say ours is 350K and contains a lot of code about a lot of things. say our site is fairly large (a few hundred pages), but is that how big the file should be?

Clearly what is running now in your particular case is not stable enough to cause core dumps, so I can’t see how it would hurt.

095 cleans up a lot of bugs, and it also should be more secure as lots of areas are tightened up. We are currently working on the default content and some last-minute minor corner case bugs for the release. Expect a final beta or RC next week.

FWIW, this is also the first report we’ve had of core dumps. Who’s hosting your site?