out of memory error in document.parser.class.inc.php (line 1296) in 0.95

Hi all,

I have an big problem: I can’t access my site anymore. On the user-interface the following error occurs:
Fatal error: Allowed memory size of 67108864 bytes exhausted (tried to allocate 13136670 bytes) in /mnt/webspace/02/16348/hannoversche-schweisshunde.eu/manager/includes/document.parser.class.inc.php on line 1296.

Content of document.parser.class.inc:
function logEvent($evtid, $type, $msg, $source= ’Parser’) {
$msg= mysql_escape_string($msg);
$source= mysql_escape_string($source);
$evtid= intval($evtid);
if ($type < 1)
$type= 1;
else
if ($type > 3)
$type= 3; // Types: 1 = information, 2 = warning, 3 = error
$sql= "INSERT INTO " . $this->getFullTableName("event_log") . "(eventid,type,createdon,source,description,user) " .
"VALUES($evtid,$type," . time() . ",’$source’,’$msg’,’" . $this->getLoginUserID() . "’)";
$ds= $this->dbQuery($sql);
if (!$ds) {
echo "Error while inserting event log into database.";
exit;
}

}



I can see the access login screen, but I cant login anymore. (password error in separate screen)

I think I need to clean the event.log table in the database...
(But I don’t have access zu the database from here right now.)

You’ll need to provide more information in order for us to be able to offer a suggestion. Please see the "help us help you" link in my signature. Thanks!

Schwieni and Ryan,
I have encountered the same problem. In my case, the error message points to a different line number (1287 instead of 1296), but here’s the message:

Fatal Error: Allowed memory size of 8388608 bytes exhausted (tried to allocated 1679631 bytes) in
{path-to-MODX}/manager/includes/document.parser.class.inc.php on line 1287

In the same way as Schwieni, the entire site is now stopped functioning, so getting the details on the mysql and php will require me to login on an ssh connection.

We have a pretty vanilla site at this point, though there are two plugins we have added to the standard 0.9.5.1 install:
XSLT and Kalender.

My suspicion is that this is a memory leak somewhere in PHP/MODx and our ISP (NTT/Verio) is protecting their server by shutting down the process automatically. I’ll let you know more as I continue my investigation.

Fortunately, we are still in development right now, or this would be a real issue - I sure hope I can get an understanding of the root cause of this before we go live with the new site. Right now, I don’t know how to consistently create this situation, so I don’t know how to know when it is fixed. Last time, our ISP killed and restarted a few processes that seemed to have grown too big...(I was not directly involved in fixing this the last time.)

Just wanted to weight in that Schwieni is not alone in seeing this problem, and it is ultimately a pretty critical one for us.

TomLR

A few more bits of information about this issue.

1.) Getting the sever back - we were able to get the server back by restarting mySQL. With VERIO, you go to the control panel, "yourdomain.com/ControlPanel", then "Add Ons", then select "MySQL" then look for the button, "Disable MYSQL" After you have disabled mySQL, you can enable it, and that effectively starts and stops the server. ( I don’t currently have shell access to this server, so this was a handy thing to learn how to do.)

2.) Once we restarted the server, I could get the some of the environmental info for our server (per Ryan’s Help us Help You" link):
[table]
[tr] [td]PHP Version: [/td] [td]4.4.4[/td] [/tr]
[tr] [td]Server API: [/td] [td]CGI[/td] [/tr]
[tr] [td]Server [/td] [td]Apache 1.2.27/td] [/td][/tr]
[tr] [td]OS Version: [/td] [td]FreeBSD 4.10 release #7[/td] [/tr]

[/table]

Looks like we are running mySQL version 4.4.1, but I’m not 100% sure. Would be nice if ModX included that info in their siteinfo section (I think it’s just "select version()"... Anyway, hope that helps others.

I’m not confident about going live with the new ModX site until we understand better why we are seeing this errror (once a week or so.) I am not seeing similar errors on other ISPs where I have active MODX based websites...

Schwieni - who is your ISP? Does restarting mySQL temporarily resolve the issue?

Cheers,

TomLR

howdy all..

sadly, i too am a new member of the document.parser.class memory error club

restarting MySQL worked out ok - had it been a data-critical emergency, it wouldn’t be too bad since I was able to retrieve the database, content of the site, etc.

in my case, the sequence of errors and warnings seemed to be initiated by an attempt to enable the ’Use Friendly URLs’ option [Manager->Tools->Configuration->Friendly URLs] .

some fOpen/fRead/fClose errors followed the memory error and some other wierdness. i’ve had to deal with some funky issues on our server when attempting to use mod_rewrite dependent stuff and/or other SEF methods in the recent past, and normally i can hack away at .htaccess for a fix if not available on a forum. haven’t tried that yet, i probably have bypassed or misread some instructions as which is most often the case w/me.. if i get it sorted i’ll try to report anything i figure out. i’ll also document to the best of my ability what led up to the error if i can replicate it.

but for the time being, what i’m wondering is what others who experienced similar errors were actually doing when it got screwy - and if there was anything notable as far as avoiding next time. thanx much.

cheers and thanks,

::drew::

---

Web Server:
* PHP version and how it’s running (suexec, mod_php, CGI, etc.)
PHP Version 4.4.4 (CGI) -and- PHP Version 5.2.0 (CGI) {let me know if full config would help}
* Apache or IIS version
Apache 1.3.37
* Operating System and version
FreeBSD 4.10

Database:
* MySQL version
MySQL 4.1.21
* List of any tables over 1MB in size
none

MODx:
* Version
0.9.5
* Any changes you’ve made
Minor TinyMCE modifications, such as custom styles
MRW - MODx Resource Wizard script
SkinGraft
MaxiGallery
a few templates from repository
a few chunks and snippets required/used by themes etc.
* Any snippets you’re running on the page that is not working properly
all snippets working correctly
* Any plugins you’re running
TinyMCE

Browser/Client:
* Browser name and version
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3
* Operating System and version
System Version: Mac OS X 10.4.9 (8P135)

robot, please see the "help us help you" link in my signature. Thanks.

hey.. i just want to confirm the server and database configuration and specs, then will post all details in the ’Help Us Help You’ area. thanx.

::drew::

*edit -> noted, i will update the original post

I have updated my original post regarding another instance of this error.

I also got an error message for line 1296, but in my case it was a php timeout (php 5.1.6, code didn’t exit within 30 seconds). I recently upgraded my php version from 5.1.4, which didn’t give me this problem.

After this, I upgraded to php 5.2.2, which gave me the ’Fatal error: Allowed memory size of 8388608 bytes exhausted in document.parser.class.inc.php on line 1296’.

However, as far as I can see, I found out that the error comes from getLoginUserID() which in certain cases doesn’t return any value at all. The function contains several elseif statements which return a value, but no final else or return statement. Apparently this causes logEvent() to hang, when it calls getLoginUserID() to build the insert statement (which is done on line 1296).

When I added ’return 1;’ at the very end of getLoginUserID(), the system didn’t hang anymore. As this is the admin id, this isn’t probably very safe, but in this case it works The problem is that the code in logEvent() expects a current userId, but this is only the case if someone is actually logged in (either front- or backend). Am I right?

I still don’t understand why this problem shows up at this moment, because I’ve been working with this version of MODx since december 2006. I did format my computer and install a slightly newer version of php recently. Oh well.

JW

OS: XP Pro
PHP: first 5.1.6 and then 5.2.2 (both as CGI)
MODx: 0.9.5 (rev 2106)
MySql: 5.0.22

robot, when it says " * Any snippets you’re running on the page that is not working properly" that’s probably not completely clear. That means please list all snippets that are on the page that is failing. Also do the same for any plugins that are enabled while you’re at it.