CiviCRM Community Forums (archive)

I'm not sure that you are going down the right path here.

I would investigate where your memory is going - it may be that although the final symptom is a call into PEAR, the problem might be the number of Apache processes or mail processes, or the Apache processes gradually each getting bigger.  There's some useful information on relevant commands at http://rimuhosting.com/howto/memory.jsp.

Sometimes you may need to increase the php maximum memory limit for CiviCRM, especially if you've just upgraded from D6 to D7.

But before spending too much time on this, I'd emphasize that often it is easier and less expensive to just increase the server RAM to see if that helps.

config_backend stores some of your civicrm settings in a "serialized" (a php function, check php manual) in the DB. Both those values seem quite off. Its typically quite a long string. In my local install the length is 2732 characters and starts off with

a:74:{s:10:"lcMessages";s:5:"en_US";s:25:"monetaryThousandSeparator";s:1:",";s:20:"monetaryDecimalPoint";s:1:".";s:11:"moneyformat";s:5:"%c %a";s:16:"moneyvalueformat";s:3:"%!i";s:12:"countryLimit";a:3:{i:0;s:4:"1228";i:1;s:4:"1101";i:2;s:4:"1226";}s:13:"provinceLimit";a:1:{i:0;s:4:"1228";}s:21:"defaultContactCountry";s:4:"1228";s:15:"defaultCurrency";s:3:"USD";s:14:"legacyEncoding";s:12:"Windows-1252";s:23:"customTranslateFunction";s:0:"";s:14:"fieldSeparator";s:1:",";s:11:"_qf_default";s:17:"Localization:next";s:21:"_qf_Localization_next";s:4:"Save";s:13:"inheritLocale";i:0;s:21:"defaultCurrencySymbol


This string is typically updated only when the settings screens are updated (i.e. u change the value of a setting)

On initialization if it find a null value, it creates a default set of values

lobo

JoeMurray: We assumed it was safe to delete all the config_backend value but I don't think this is the case in a multi-lanugage environment as it causes other issues we have found.

Lobo: With further investigation this is the actual error we get underneath the PEAR memory error. The error is something to do with a missing title field but I can’t see any relevant to why it is there in this instance.

Also attached is the config_backend value that causes the problem. may only be valid in a mult-lanuage environment.

PEAR Error $message variable listed below:

DB_Error Object
(
    [error_message_prefix] =>
    [mode] => 16
    [level] => 1024
    => -19
    [message] => DB Error: no such field
    [userinfo] => SELECT civicrm_uf_group.id, title, civicrm_uf_group.is_active, is_reserved, group_type
                        FROM civicrm_uf_group
                        LEFT JOIN civicrm_uf_join ON (civicrm_uf_group.id = uf_group_id) AND civicrm_uf_group.is_active = 1
                              WHERE civicrm_uf_join.module = 'User Account' ORDER BY civicrm_uf_join.weight, civicrm_uf_group.title [nativecode=1054 ** Unknown column 'title' in 'field list']
    [backtrace] =>
)



Any Ideas as to why we would get this error of missing title field in this situation?

Thanks

JoeMurry: Very helpful reply, thanks.
I will investigate this further and report any further findings back to this post.

Okay, i think i've just run into this issue, which might be a repeat of several threads, like these ones:

http://forum.civicrm.org/index.php?topic=20547.0
http://forum.civicrm.org/index.php?topic=18688.0

My circumstances are with making a dev copy of a D6/CiviCRM3.3.6 mulitlingual site, so I think the multilingual is some kind of issue here. I tried setting the config_backend to blank and it didn't help.

The first layer has been identified earlier in this thread - that the PEAR debug is failing, going into some kind of loop. As a first step, i edited line 882 of the PEAR.php script to just do a straight print_r(debug_backtrace()); die(); instead of the fancy stuff that was breaking in there.

When I look at that backtrace - I see that the actual error is a db access error, and it's trying to access it with the production user/passwd (not set up on my dev machine).

So I guess that means the database credentials are somehow being cached in the database? Sounds like a bad idea?

Here's the sql:

SELECT v.name as valueName, v.value, g.name as optionName
FROM   civicrm_option_value_en_US v,
       civicrm_option_group_en_US g
WHERE  ( g.name = 'directory_preferences'
OR       g.name = 'url_preferences' )
AND    v.option_group_id = g.id
AND    v.is_active = 1

The debug_backtrace shows that the code goes bad during the drupal configuration, so i think it's related to the language negotiation.

In any case - my solution was to add the mysql credentials from my production server, but I think my specific issue might enlighten this general problem.

I can send someone the full backtrace if that's helpful.

I'll try and recreate it on a publicly accessible server, but it'll have to wait til next week.

As I think about it again ... it's quite confusing to me that it was trying to access the server with those production credentials.

The site was originally set up as a single-language site, and then we had to make the mysql user a super user to allow the multi-language thing. Then I gave in and upgraded them to Mysql 5.1 and that allowed me to downgrade some of those superpowers. All that was on the production server (not in production yet ...), so I'm not sure how all of that might have left the tables, etc. Those mysql super powers and related trigger things are definitely outside my scope and comfort zone ...