Can't open Boost Settings [#1297726]

I've been using Boost for a couple of months now and everything is working as it should (to the best of my knowledge). Lately, however, I am unable to access Boost Settings page.

Whenever I tried to open the settings page I get the error message:
Fatal error: Out of memory (allocated 99614720) (tried to allocate 96 bytes) in /home/mysite/public_html/sites/all/modules/boost/boost.admin.inc on line 1210

I've been using 128M of memory and tried increasing that to 256M, but the problem didn't go away.

Comments

Comment #1

Methos76 CreditAttribution: Methos76 commented 5 October 2012 at 12:14

Assigned:

qwert123

» Methos76

sorry for bringing this up, but I have the same problem.
I looked at the code in the boost.admin.inc and it seems to me that boost is trying to geht the count of all files in the cache folder. Having a (very) big page, this seems to be a problem, so the memory runs off.

At the moment i even don't understand why boost is dooing that. If boost wnats to know how many files are cached and how many are expired, it could look into the database to get this information.

I think I will comment this area out and look what happens to get the settingspage online again..

(Update Inserted)
Ok now i Know for what boost is counting the files ..
last Point of the page is Clear Boost's Database & File Cache.
And on the button the count of the files is part of the output ...
but is it really needed?

(update ends)

TO reproduce this problem you need a page without clearing expired on cron ( and not cleaning anyway at all ) some day you seem to run into this problem.

Comment #2

Anonymous (not verified) CreditAttribution: Anonymous commented 5 October 2012 at 18:37

I believe these are two differing issues. The original post appears to be an out of memory error due to a loop caused in the domain wildcard system but the line listed is in the form submission and may not be boost, it might be domain access.

Whereas this post doesn't make a lot of sense regarding file size as at no point are the cached files brought into memory, they are counted and a variable is incremented but it appears unlikely that the size of a file is the issue, what did you disable to get the page working again ? In the page counting function there is also a timer to break the loop if it becomes excessive.

Was your error at line 1210 too ?

Comment #3

bgm CreditAttribution: bgm commented 5 October 2012 at 18:44

Version:

6.x-1.18

» 6.x-1.20

The list of files is to count CSS/JS files that could be cached in "cache/perm/".

I also think that the boost_count_all_files() checks all the "cache/" directory, which means it will count for all the sites listed in the same code base (multi-site).

boost_count_all_files(BOOST_ROOT_CACHE_DIR)

The file count is kind of useful, but I'd be in favor of removing that one. Hesitating whether to do this in a 6.x-2.x branch (where regressions may happen).

Also agree with Philip_Clarke's comment that the two posts may not refer to the same thing.

@ qwert123: can you edit boost.admin.inc, find "function boost_count_all_files($path, &$timer = NULL, $first = TRUE) {" and add:

function boost_count_all_files($path, &$timer = NULL, $first = TRUE) {
  return 0;  // <-  add this
[...]
}

Comment #4

Methos76 CreditAttribution: Methos76 commented 12 October 2012 at 12:34

Whereas this post doesn't make a lot of sense regarding file size as at no point are the cached files brought into memory,

I do not find any sentence in my post, that could let someone assume i would think, the cached files would be brought into memory .. sorry, but where did you take that from?

In the page counting function there is also a timer to break the loop if it becomes excessive

That doesn't help if memory consumption is too big ..

what did you disable to get the page working again?

I did what bgm did in post #3. I made boost not count the files.

And yes the error was also in lin 1210, and I do not use domain access in this project.
So i still think boost seems to cause this error under some circumstances.

Comment #5

Anonymous (not verified) CreditAttribution: Anonymous commented 12 October 2012 at 13:29

Having a (very) big page, this seems to be a problem, so the memory runs off.

this sentence refers to a big page. Which version of php and are there are symlinks in the file systems ? because i can look at it again and try and find why the loop becomes infinite. Is your boost cache in the normal place (under cache/normal/domain.name/) and how is PHP being run ? as a process of fast-cgi (I'm thinking on the fly here by it PHP lost it's reference point to the directory, it might just decide to count outside of the filesystem, I've seem a watch_dog error tat highlights that somewhere).

Comment #6

Methos76 CreditAttribution: Methos76 commented 18 October 2012 at 10:18

The php Version is 5.3.2
php is run as apache-module
there are indeed symlinks in the filesystem ( in the directory drupal is installed in )
Cache is placed in normal place

hope that helps to find out why the loop does consume so much memory and is not terminating as expected.