Jump to content
brian_cee

Fatal error, webhost is stumped

Recommended Posts

I have 2.3.4.1 BS, been building this site for a while, only a couple hundred products, no traffic really going there yet.

I tried to add a category in the admin area of my site's shop, and the page broke and I got this:
Fatal error: Allowed memory size of 805306368 bytes exhausted (tried to allocate 61440 bytes) in /home/username/public_html/store/myadmin/includes/functions/general.php on line 195

(Line 195 says:  if ($exclude != $categories['categories_id']) $category_tree_array[] = array('id' => $categories['categories_id'], 'text' => $spacing . $categories['categories_name']);)

I contacted my host, and first they increased memory:
memory_limit = 768M

when that didn't work they added this line to /admin/includes/functions/general.php:

ini_set("memory_limit","128M");

When that didn't work they said it's not them, it's the software not working properly.

Does anyone have any idea where I can find a solution to this?

Share this post


Link to post
Share on other sites

That code is in the section that reads in the categories. If you have, for example, 1,000 categories, that could cause such a problem. There could be other reasons but I would check that first. Also, is the problem only in admin->Catalog or does your shop side cause the failure too?

Share this post


Link to post
Share on other sites

Well,  768MB of virtual memory is a butt-load to use up. As suggested, do you have a huge number of categories already defined (how many)? Anything else in huge numbers? Are your images of reasonable size (not 100MB each, to be scaled down by the browser)? What PHP version, what add-ons, etc.? Anything unusual in your configuration or data that you can think of? Can you run your phpinfo() and see if all numbers, especially memory size(s), look reasonable and expected, and match your php.ini?


If you are running the "official" osC 2.3.4 or 2.3.4.1 download, your installation is obsolete! Get (stable) Frozenpatches or (unstable) Edge. See also the naming convention and the latest community-supported responsive "Edge" release

Share this post


Link to post
Share on other sites
1 hour ago, brian_cee said:

I tried to add a category in the admin area of my site's shop, and the page broke and I got this:

As you only have a few hundred products, the fact that you broke the cat page is probably at the root of your problem, the cat table may have been corrupted by that broken page You could should restore from a known good backup and see if that fixes the problem first. Key will be what did that cat you attempted to add contained?

 


 

Share this post


Link to post
Share on other sites
7 hours ago, Jack_mcs said:

That code is in the section that reads in the categories. If you have, for example, 1,000 categories, that could cause such a problem. There could be other reasons but I would check that first. Also, is the problem only in admin->Catalog or does your shop side cause the failure too?

I was going to say admin only, but now all of a sudden just going to the site shows this instead of home page:

Fatal error: Allowed memory size of 536870912 bytes exhausted (tried to allocate 159744 bytes) in /home/~username/public_html/shop/includes/classes/category_tree.php on line 80:

 $result .= str_repeat($this->spacer_string, $this->spacer_multiplier * $level);

And I only have one category.

 

Edited by frankl
Remove sensitive info

Share this post


Link to post
Share on other sites
10 minutes ago, JcMagpie said:

As you only have a few hundred products, the fact that you broke the cat page is probably at the root of your problem, the cat table may have been corrupted by that broken page You could should restore from a known good backup and see if that fixes the problem first. Key will be what did that cat you attempted to add contained?

 

The new category didn't contain anything, yet, I was still in the process of adding stuff, so I was just going to start a new category and add new products to it....I'll try to add a new cat table like you suggested.

 

Share this post


Link to post
Share on other sites
35 minutes ago, MrPhil said:

Well,  768MB of virtual memory is a butt-load to use up. As suggested, do you have a huge number of categories already defined (how many)? Anything else in huge numbers? Are your images of reasonable size (not 100MB each, to be scaled down by the browser)? What PHP version, what add-ons, etc.? Anything unusual in your configuration or data that you can think of? Can you run your phpinfo() and see if all numbers, especially memory size(s), look reasonable and expected, and match your php.ini?

Only one category, about 200 products which have one image each, and all images are around 100kb each. PHP version is 7.0.31.....Addons are minimal, Magic Zoom, PWA, Ultimate SEO URL, Modular Shopping cart, Google XMO sitemap, really just basic stuff. I am not sure what that phpinfo stuff means, but in my admin server info section, memory_limit is at 128 and 768, local value and master value, whatever that means....

Share this post


Link to post
Share on other sites
1 hour ago, MrPhil said:

 Can you run your phpinfo() and see if all numbers, especially memory size(s), look reasonable and expected, and match your php.ini?

OK, I made that file, phpinfo.php and uploaded it, and memory size says 768M which matches the php.ini.........

Share this post


Link to post
Share on other sites

I think the master value is the server-wide max value, and the local value is what is set for your account/page. 128MB is usually enough in most cases, but since you probably have some headroom (768MB), you could see if something larger in your php.ini or with an ini_set() makes any difference. If increasing to, say, 192MB cures the problem, you might leave it at that, but generally it's better to understand what's going on than to simply raise limits until it stops breaking. At least, it could buy you some time to figure out what's eating up so much memory.

$result .= str_repeat($this->spacer_string, $this->spacer_multiplier * $level); 

Any chance of temporarily inserting the following diagnostic just before that line:

echo "str_repeat('".$this->spacer_string."', ".$this->spacer_multiplier." * ".$level.")\n";

and seeing if the string is absurdly long, or the multiplier or level is huge? 159744 bytes is awfully large for a string temporary. The problem could also be that $result is caught in an endless loop and building up until it crashes the system (it wasn't the str_repeat that is the problem).

Edited by MrPhil

If you are running the "official" osC 2.3.4 or 2.3.4.1 download, your installation is obsolete! Get (stable) Frozenpatches or (unstable) Edge. See also the naming convention and the latest community-supported responsive "Edge" release

Share this post


Link to post
Share on other sites
3 minutes ago, MrPhil said:

I think the master value is the server-wide max value, and the local value is what is set for your account/page. 128MB is usually enough in most cases, but since you probably have some headroom (768MB), you could see if something larger in your php.ini or with an ini_set() makes any difference. If increasing to, say, 192MB cures the problem, you might leave it at that, but generally it's better to understand what's going on than to simply raise limits until it stops breaking. At least, it could buy you some time to figure out what's eating up so much memory.


$result .= str_repeat($this->spacer_string, $this->spacer_multiplier * $level); 

Any chance of temporarily inserting the following diagnostic just before that line:


echo "str_repeat('".$this->spacer_string."', ".$this->spacer_multiplier." * ".$level.")\n";

and seeing if the string is absurdly long, or the multiplier or level is huge? 159744 bytes is awfully large for a string temporary.

I don't think I can change the php.ini thing, because I believe you have to restart Apache for it to take effect, and I can't do that with my shared account.

I did add that line before line 80 on that file, but I'm not sure where to see results, now my sites homepage is just blank.

 

Share this post


Link to post
Share on other sites

Some server accounts permit you to define a php.ini file for yourself. Ask your host if there is something like that you can use. The alternative would be to put ini_set() in application_top.php so every page gets it.

Assuming you or I didn't make a syntax error, is there any page source in the browser (Ctrl+U, usually)? If completely empty, there must be something wrong with the new statement. Or, if the server choked with millions of lines of output, that would suggest an endless loop on that page.


If you are running the "official" osC 2.3.4 or 2.3.4.1 download, your installation is obsolete! Get (stable) Frozenpatches or (unstable) Edge. See also the naming convention and the latest community-supported responsive "Edge" release

Share this post


Link to post
Share on other sites
8 minutes ago, MrPhil said:

Some server accounts permit you to define a php.ini file for yourself. Ask your host if there is something like that you can use. The alternative would be to put ini_set() in application_top.php so every page gets it.

Assuming you or I didn't make a syntax error, is there any page source in the browser (Ctrl+U, usually)? If completely empty, there must be something wrong with the new statement. Or, if the server choked with millions of lines of output, that would suggest an endless loop on that page.

I'm not sure asking my host to do anything is in the cards after what I put them through yesterday.....But when I look at the source of that blank page by doing the Control-U thing, that was blank also........I'm at a loss.....

Share this post


Link to post
Share on other sites

Well, comment out the echo statement I had you add, and see if you're back to where you were. See if you have any error_log or similar files floating around that might detail what the error is. There might also be a server error log under your account control panel that might say something.

I don't think I've ever seen a host that didn't permit you to add PHP settings somewhere. On very old systems, they might be php_value or php_flag settings in your .htaccess. Others might have something similar to php.ini, but called something different. As a last resort, ini_set() calls can be added, but that's the sign of a bogus host if that's the only way.


If you are running the "official" osC 2.3.4 or 2.3.4.1 download, your installation is obsolete! Get (stable) Frozenpatches or (unstable) Edge. See also the naming convention and the latest community-supported responsive "Edge" release

Share this post


Link to post
Share on other sites
15 minutes ago, MrPhil said:

Well, comment out the echo statement I had you add, and see if you're back to where you were. See if you have any error_log or similar files floating around that might detail what the error is. There might also be a server error log under your account control panel that might say something.

I don't think I've ever seen a host that didn't permit you to add PHP settings somewhere. On very old systems, they might be php_value or php_flag settings in your .htaccess. Others might have something similar to php.ini, but called something different. As a last resort, ini_set() calls can be added, but that's the sign of a bogus host if that's the only way.

Commenting it out didn't change anything, so I just removed it, and I'm back where I was, with the original Fatal Error message instead of a page. My error logs in Cpanel don't have anything, and my OSCommerce php_errorlog just have listed the same error that shows up on the page, saying the memory has been used up, etc...

Share this post


Link to post
Share on other sites
19 minutes ago, ArtcoInc said:

@brian_cee

Do you have a full backup of your site (both files AND database) before the crash?

Malcolm

Yeah, I'm just restoring the whole database at the moment, but I don't know if that will work, or what initially caused it......

Share this post


Link to post
Share on other sites

@brian_cee   If you have your shop in subdirectory the increased memory will not work because the PHP settings defined in your php.ini file are not recursive. What this means is that they do not modify settings in any child folders (which are subdirectories of the current directory).

so  Update your suPHP_ConfigPath in your .htaccess file

suPHP_ConfigPath /home/username/public_html

This line you entered is specifying the directory where the php.ini is located that you want to make recursive. Be sure to replace username with your  username.

Share this post


Link to post
Share on other sites

@brian_cee edit your 2nd post to remove personal detail from path

a bit heavy duty so only run for a short time

add this to your admin htaccess file

LogLevel debug
RewriteLogLevel 8
RewriteLog /a path you have access to for your logs/logs/rewrite.log

that will give you a log of everything so that you can pin down the cause


No longer giving free advice. Please place deposit in meter slot provided.  Individual: [=] SME: [==] Corporation: [===]
If deposit does not fit one of the slots provided then you are asking too much! :P


Support The Project
Documentation/Knowledgebase/Discussions
 

Share this post


Link to post
Share on other sites

The shopside error reason is here:
https://github.com/osCommerce/oscommerce2/blob/de9e922377cbfd0678c9e4b9e8eb51123f3e230a/catalog/includes/functions/general.php#L549

And the admin side reason is here:
https://github.com/osCommerce/oscommerce2/blob/de9e922377cbfd0678c9e4b9e8eb51123f3e230a/catalog/admin/includes/functions/general.php#L209

probably the new categories_id is 0 or null

another case when parent_id = categories_id = 1

Edited by tothcom

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×