I have CB and CB Subs installed, and I am getting fatal memory errors such as 'Fatal error: Allowed memory size of 50331648 bytes exhausted (tried to allocate 307201 bytes) in /public_html/libraries/joomla/environment/response.php on line 195' when accessing the Settings for CB Subs. The file that throws the error seems to change each time I attempt to access it.

All extensions are up to date, and I had a long chat with the host (Bluehost) about the issue. I had done the usual task of increasing the memory_limit in php.ini to 256M, but that didn't help. Here is our conversation:

Mike: [9:41:30 AM] I am getting a 'Allowed memory size' error on my Joomla site. I tried increasing the memory_limit in php.ini to 256M, but that didn't work. How do I increase the memory limit?
Aaron B.: [9:44:31 AM] Still getting the error?
Mike: [9:45:12 AM] Yes: Fatal error: Allowed memory size of 50331648 bytes exhausted (tried to allocate 302546 bytes) in /public_html/xx15f/libraries/joomla/environment/response.php on line 149
Aaron B.: [9:46:47 AM] Its pulling up for me. I raised the POST limit to 256m as well. Have you refreshed your cache?
Mike: [9:47:18 AM] It's only specific pages on the administrator back-end
[9:47:24 AM] when it has to load scripts
[9:47:28 AM] /administrator/index.php?option=com_comprofiler&task=editPlugin&cid=519&action=showparams&cbprevstate=b3B0aW9uPWNvbV9jb21wcm9maWxlciZ0YXNrPWVkaXRQbHVnaW4mcGx1Z2luaWQ9NTE5
Aaron B.: [9:47:46 AM] Is it in particular plugins?
Mike: [9:47:57 AM] probably
[9:48:33 AM] Here's another page:
[9:48:38 AM] Fatal Error: Allowed memory size of 50331648 bytes exhausted (tried to allocate 2600 bytes) in components/com_comprofiler/plugin/user/plug_cbpaidsubscriptions/cbpaidsubscriptions.php on line 51
Aaron B.: [9:50:10 AM] Generally it will try to allocate a few bytes, not thousands. It seems like the plugins may not be working correctly. Let me check a few things.
Mike: [9:50:44 AM] well..it's a big ecommerce plugin
[9:50:53 AM] connects to a payment gateway, etc
Aaron B.: [9:55:35 AM] Yeah, the php.ini has updated if you go to bbgreen.org/phpinfo.php the memory limit is: "memory_limit 256M 256M" I'm not sure what is happening with the plugin, but it doesn't seem to actually be memory related.
Mike: [9:56:23 AM] is there a memory cap on the server?
[9:57:02 AM] 50331648 bytes is not 256MB, is it?
Aaron B.: [9:58:09 AM] No it is not, that's why it doesn't seem to be the actual memory limit being the issue. You are erroring out a little over 50MB. The server allows up to 256MB, so that wouldn't be the issue either.
Mike: [9:58:52 AM] is there a way to verify the allocation?
[10:02:12 AM] it seems to be several unrelated plugins that throw the error
Aaron B.: [10:04:48 AM] Seeing this as fixing to this particular error: Go to AceSEF=>Configuration=>Instant Cache and set it to No please.
[10:05:48 AM] on a few different places, Do you use AceSEF?
Mike: [10:05:53 AM] Attempting..
[10:06:04 AM] i don't think so
[10:06:12 AM] i'll check
[10:07:04 AM] there's a built in SEF module in the Joomla core
[10:08:40 AM] i cleared system cache to no avail
[10:10:29 AM] Another fatal error trying to access the same thing..this time with a different file
Aaron B.: [10:10:29 AM] Still looking into it, just a few more minutes.
Mike: [10:10:31 AM] Fatal error: Allowed memory size of 50331648 bytes exhausted (tried to allocate 113 bytes) in /home4/betterj5/public_html/xx15f/libraries/joomla/language/language.php on line 736
[10:11:28 AM] language.php is a small core Joomla file...the error shouldn't be coming from the file.
Aaron B.: [10:21:58 AM] Bigger errors are coming up under [07-Aug-2011 10:09:31] PHP Fatal error: Allowed memory size of 50331648 bytes exhausted (tried to allocate 45000 bytes) in /home4/betterj5/public_html/xx15f/components/com_comprofiler/plugin/user/plug_cbpaidsubscriptions/cbpaidsubscriptions.php I would recommend going to the developer of the plugin and seeing if they know exactly what is going wrong with each error you getting from it.
Mike: [10:23:01 AM] Okay. I checked their forums, and saw memory errors pop up a lot...most of the fixes revolved around increasing the memory limit, which we tried. I'll see if they can help.
Aaron B.: [10:24:39 AM] If you find anything else that we can assist with let us know, but there is too many errors coming up under that one plugin to really narrow it down from our end.
Mike: [10:24:51 AM] Okay. I appreciate it
Aaron B.: [10:24:59 AM] have a good day!

Any idea what can be causing this?

Nick and Krileon. Thanks for your feedback. I did a little more digging and found that the Joomla PHP Information is reporting 48MB (Local) and 64MB (Master).

Additionally, I ran the memtest that was posted on the article Nick wrote, and it executed up to 230MB. Obviously, I'm getting conflicting reports. I talked to the host again, and the conversation is below. No surprise, they are still saying it's an extension problem. I'm going to make a ticket for the higher-level techs, but he said to ask you guys if there was any way the php.ini might be overridden by Joomla or CB. Could that be happening?

Sir Lonny: [7:51:18 PM] Welcome to our real-time support chat. How can I help you today?

Mike: [7:51:18 PM] I am getting memory errors such as 'Allowed memory size of 50331648 bytes exhausted (tried to allocate 748 bytes)' on my Joomla site. I increased memory_limit in php.ini to 256M, and verified with phpinfo() that it is set to 256M, but the PHP information in the Joomla backend is showing memory_limit is set to 48M, which is consistent with the memory size the errors are returning. How do I fix this?

Sir Lonny: [7:54:12 PM] Your account looks to be set properly.

Mike: [7:54:34 PM] I made these changes a few days ago, and then talked to another Bluehost tech support person who claimed it was a Joomla extension causing the problem. I created a thread on the extension's forum, and the feedback I got indicated it is a hosting problem. Here is a link to the thread: www.joomlapolis.com/forum/153-professional-member-support/172124-memory-error-that-host-cant-figure-out#172199

[7:55:42 PM] phpinfo() is showing 256M, the Joomla backend PHP information is showing 48M. The errors I get consistently report 50331648 bytes. That is much closer to 48M than 256.

[7:56:36 PM] Please read the thread. You will see the previous Bluehost tech support person's response, in addition to feedback from the extension developer, with a link explaining the exact issue in detail.

Sir Lonny: [7:56:45 PM] I've read the thread.

[7:58:45 PM] What steps do I need to take to replicate the memory error?

[8:00:21 PM] In the top menu of the Joomla administration panel, go to Community Builder -> User Management

[8:00:58 PM] You'll see the error there. You'll also see it at Paid Subscriptions -> Settings

[8:01:36 PM] And pretty much every subcategory in GroupJive

Sir Lonny: [8:02:15 PM] Okay, one moment.

Mike: [8:04:04 PM] To see the PHP memory_limit as reported by Joomla, go to Site -> System Information -> PHP Information tab and scroll down

Sir Lonny: [8:10:21 PM] Just a few more moments.

Mike: [8:10:54 PM] no problem..take all the time you need..i really need this solved

Sir Lonny: [8:18:00 PM] Okay, your account is definitely set properly. It looks like your Joomla install is manually modifying the memory_limit to 48M.;

[8:18:37 PM] If you look at the system info, you'll see that the local is set to 48M, but the Master Value is set to 256M.

Mike: [8:18:56 PM] hmm...

Sir Lonny: [8:19:08 PM] I'm not sure where it is setting it, though.

Mike: [8:19:27 PM] The master says 64M, at least in Joomla

Sir Lonny: [8:20:29 PM] I'm still seeing 256M on my end in Joomla. Regardless though, it is needing just a tiny bit more than 48M. 64M should be perfect as well.

Mike: [8:21:30 PM] Is there any way to trace the memory allocation to see where the rest is going?

Sir Lonny: [8:22:17 PM] I'm sure there is, but I don't know of a way. I checked with a higher level tech and your settings should be good. If you can't figure out where the ini_set() directive is being used, you can try opening a ticket to our Site Compatibility team and they can take a further look for you.

[8:22:19 PM] To make a ticket, you can visit this url link: helpdesk.bluehost.com/index.php/contact

Mike: [8:23:21 PM] Is it possible the php.ini isn't working in the subdirectory Joomla is installed?

Sir Lonny: [8:24:32 PM] No, because it is being read by Joomla. It is just being overridden by a directive within Joomla. Likely one of your plugins. Loaded Configuration File /home4/betterj5/public_html/php.ini is what Joomla is reporting.

Mike: [8:25:02 PM] but that's the correct one

Sir Lonny: [8:26:07 PM] Yes, it is.

Mike: [8:26:36 PM] This is very confusing. Extension devs say it's a hosting setting, host says it's an extension problem

[8:27:14 PM] I'll check with them and see if there is a php.ini override anywhere in the extension.

Sir Lonny: [8:27:44 PM] Okay, sounds good. I'd also recommend the ticket as well to our Site Compatibility team. That's probably the best avenue of support.

Mike: [8:27:58 PM] I'll do that. Thanks for your help

Sir Lonny: [8:28:38 PM] Not a problem. Have a nice night!

[8:28:39 PM] Thank you so much for contacting support, and please let us know if you have additional questions in the future.

[8:28:40 PM] If interested, a great deal of valuable information can be found in our knowledge base at: helpdesk.bluehost.com/ and in our video tutorials at: tutorials.bluehost.com.

Hey guys,

Bluehost was able to fix the problem. Apparently it WAS files in the extension that were overriding php.ini.

I want to thank everybody here for their help. For the sake of helping anyone else who might be having this problem, here is what the higher-level tech support person said he did to fix the problem:

---

Hello,
Thanks for contacting support.

The people commenting on the forum saying that this is a server problem could not possibly do anything more than guess since they:
1. Do not have access to your scripts.
2. Do not have access to the hosting environment.

Here is a write up of my investigation:

You have nine php files that could modify the memory_limit setting. They are:

./components/com_comprofiler/comprofiler.php
./libraries/joomla/application/cli/daemon.php
./administrator/index.php
./administrator/components/com_rsticketspro/helpers/thumbs/phpthumb.class.php
./administrator/components/com_kunena/admin.kunena.php
./administrator/components/com_comprofiler/admin.comprofiler.controller.php
./administrator/components/com_comprofiler/install.comprofiler.php
./administrator/components/com_comprofiler/library/cb/xml/cb.xml.domit.php
./components/com_alphauserpoints/assets/phpThumb/phpthumb.class.php

I found these using the following command:
@box747:xx15f $ find . -type f -name \*.php -print0 | xargs -0 -P16 grep -l 'memory_limit' | xargs grep -l ini_set

I decided to start investigating in ./administrator/index.php, and found these on lines 12 and 13:
ini_set( 'memory_limit', '16M' );
@ini_set( 'memory_limit', '32M' );

This sets the memory limit to 16M, then immediately after to 32M. The @ in front of the ini_set() means, "Don't display any errors for this function." So at this point, we've already abandoned the memory_limit in your php.ini, which definitively makes this an issue with your script, not an issue with the server. Regardless, I'll keep digging. I commented those lines out of your administrator/index.php file..

I then searched for files specifically mentioning these three strings: 'memory_limit', 'ini_set', and '48M'. I found these two:

@box747:xx15f $ find . -type f -name \*.php -print0 | xargs -0 -P16 grep -l 'memory_limit' | xargs grep -l ini_set | xargs grep -l '48M'
./administrator/components/com_comprofiler/admin.comprofiler.controller.php
./administrator/components/com_comprofiler/install.comprofiler.php

I took at look at ./administrator/components/com_comprofiler/install.comprofiler.php first and found this:

$memMax = trim( @ini_get( 'memory_limit' ) );
if ( $memMax ) {
$last = strtolower( $memMax{strlen( $memMax ) - 1} );
switch( $last ) {
case 'g':
$memMax *= 1024;
case 'm':
$memMax *= 1024;
case 'k':
$memMax *= 1024;
}
if ( $memMax < 16000000 ) {
@ini_set( 'memory_limit', '16M' );
}
if ( $memMax < 32000000 ) {
@ini_set( 'memory_limit', '32M' );
}
if ( $memMax < 48000000 ) {
@ini_set( 'memory_limit', '48M' ); // DOMIT XML parser can be very memory-hungry on PHP < 5.1.3
}
}

That block of code does some comparisons, then at the end sets the memory_limit to 48M. I commented that entire block of code out. After I commented that block out, this page now loaded without any errors:
administrator/index.php?option=com_comprofiler&task=showusers

I found the very same block of code in ./administrator/components/com_comprofiler/admin.comprofiler.controller.php, so just for the sake of being complete, I commented it out there too.

Everything on the back end appears to be working now.

The work that I did here is very much outside the scope of our technical support, and we will not be able to repeat this in the future.