Jump to content
  • Checkout
  • Login
  • Get in touch

osCommerce

The e-commerce.

Fatal error, webhost is stumped


brian_cee

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?

Link to comment
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?

Support Links:

For Hire: Contact me for anything you need help with for your shop: upgrading, hosting, repairs, code written, etc.

Get the latest versions of my addons

Recommended SEO Addons

Link to comment
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?

Link to comment
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?

 

 

Link to comment
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.

 

Link to comment
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.

 

Link to comment
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....

Link to comment
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.........

Link to comment
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).

Link to comment
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.

 

Link to comment
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.

Link to comment
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.....

Link to comment
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.

Link to comment
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...

Link to comment
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.

Get the latest Responsive osCommerce CE (community edition) here .

Link to comment
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

Is your Osc dated try Phoenix  raising oscommerce from the ashes.

Link to comment
Share on other sites

Link to comment
Share on other sites

  • 10 months later...
On 9/10/2018 at 12:07 AM, a123 said:

I thought I had this problem fixed, but it's happening again.....Can you tell me what you meant with the above post? I'm re-reading it dozens of time but I can't figure out how to fix anything......

 

 

Link to comment
Share on other sites

Never mind, I didn't realize it was bad form to respond to a thread that's more than a few months old.....I'll start a new thread.....

 

On 9/10/2018 at 12:07 AM, a123 said:

 

Link to comment
Share on other sites

If it's the same issue, there's no problem that it's a few months old. The problem is hijacking old threads to start talking about a different problem. That becomes very confusing when the matter being discussed suddenly lurches to something else, and the subject (title) line no longer matches up.

Link to comment
Share on other sites

On 9/9/2018 at 3:57 PM, 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. 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).

Unfortunately I have a crappy shared hosting account and don't have access to any of that ini stuff...

Link to comment
Share on other sites

On 9/10/2018 at 12:07 AM, a123 said:

I got a guy at my hosting company to do what he could. He got the shop to not be broken by uploading an older version of /public_html/shop/includes/modules/boxes/bm_categories.php

 

Then he somehow added a new category before the admin side broke again, which allowed me to go to the database and see that yes, the categories_id is "0" on the new category.

So, how do I make the database assign a number to the categories_id? If anybody knows, I'd sure appreciate your time if you could share it with me.

 

category-id.jpg

Link to comment
Share on other sites

categories table should be autoincrement so next id would be 23

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

Is your Osc dated try Phoenix  raising oscommerce from the ashes.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...