Answers.Body: <p>I just got this happening also, on a 4.6 install. It's due to an issue with your civicrm_settings table. That piece of code you reference is pulling out settings type values from that table and caching them. The code assumes that the values in there are objects or arrays and have to get serialized and unserialized as they get stuffed in and pulled out of text fields. The error is due to the code's inability to unserialize the value, which can happen if it gets serialized badly, or was never serialized in the first place.</p>
  
  <p>In your case, it looks like it's really big and exceeds the space available (since it's pulling out 24K bytes from that poor little field). In my case, there was some non-serialized data in there, possibly from a previous code version.</p>
  
  <p>All I did to fix it was to look through my civicrm_settings table and saw a lot of entries for the name 'navigation' with a non-serialized string, and removed them (they were in the Personal Preferences group and were all the same, so it seemed innocuous).</p>
  
  <p>For your case, you could find all the entries with a value length bigger than 20K and it'll probably be evident.</p>
  
  <p>I suspect you might be misusing one of your fields/features.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-10-19T01:54:26.127Z
Answers.Text: I've seen the same happen when a similar CMS table (Drupal's "variable" table) was being misused as a cache. (I've also seen a CiviCRM site inject identical "navigation" values for each user, all with the same eight-character  string, into the settings table. Alan did your "navigation" setting strings all start with "X5S"?
Answers.UserDisplayName: Chris Burgess
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-10-19T14:52:00.843Z
Answers.Text: They were all "sMtgpUbb". And they had recent but not identical 'created_date' values, so I suspect it's a current code issue. But I've only seen it on one site so far, so there might be only specific circumstances that apply. In general, whenever we're stuffing serialized objects/arrays into string fields, we're likely to hit limits at some point, so some kind of size checking might be a good idea. On the other hand, cache get/put operations are not places you want to be adding too much overhead.
Answers.UserDisplayName: Alan Dixon
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-10-20T01:56:53.660Z
Answers.Text: Thanks. Yeah all this site's 'navigation' strings were an eight-char random-looking-but-identical string. Glad to know at least one other person has seen this weirdness :D
Answers.UserDisplayName: Chris Burgess
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-10-20T02:09:52.637Z
Answers.Text: [`CRM_Core_BAO_Navigation::resetNavigation()`](https://github.com/civicrm/civicrm-core/blob/master/CRM/Core/BAO/Navigation.php#L683) Alan, in case you were intrigued ... see also [735386975](https://github.com/civicrm/civicrm-core/commit/7353869752836eeff00ab68234f0d64303cfd713) and [CRM-12337](https://issues.civicrm.org/jira/browse/CRM-12337). In combination with DB logging and a large number of contacts, `log_civicrm_setting` starts to get ... large :)
Answers.UserDisplayName: Chris Burgess
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-10-20T06:10:25.800Z
Answers.Text: Alan and Chris, thank you very much!
  I'll check everything and post the results.
Answers.UserDisplayName: David Carrillo
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-10-20T08:46:44.967Z
Answers.Text: Hi again,
  I tried to look for entries with length=25832 at civicrm_setting with no results, but there was at civicrm_cache table.
  Looking at the group_name and path, corresponds to "contact fields" and "importableFields All_0_0_0_1".
Answers.UserDisplayName: David Carrillo
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-10-25T17:18:57.153Z
Answers.Text: That 25832 number is probably too specific, just look for big ones. Anything bigger than 10K is likely something gone bad.  re: misusing fields/features, I'm going to hazard a guess that you put too much data into a custom field.
Answers.UserDisplayName: Alan Dixon
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-10-18T20:31:39.097Z
Answers.LastActivityDate: 2016-10-18T20:40:52.470Z
Answers.LastEditDate: 2016-10-18T20:40:52.470Z
Answers.UserDisplayName: Alan Dixon
Body: <p>First of all, thank you for the support. I hope I can help anybody sometime!</p>
  
  <p>I have Civicrm 4.7.12 installed in Drupal 7.51, and sometimes I get the error:
  Notice: unserialize(): Error at offset X of Y bytes en CRM_Core_BAO_Cache::getItem()  (X and Y are integer values)</p>
  
  <p>It begun after I upgraded to Civicrm 4.7.11, and no matter what I test... I can't resolve it.</p>
  
  <p>Can anybody help me?
  Thanks a million!</p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-10-13T16:09:51.617Z
Comments.Text: Welcome to StackExchange! It would be helpful if you could say what you are doing when you get this error.
Comments.UserDisplayName: William Mortada
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-10-14T11:26:35.363Z
Comments.Text: Hi Again. It shows at different points. For example, when I search a contact, or at "New mailing".
  Apparently Civicrm works well, but It shows these messages...
Comments.UserDisplayName: David Carrillo
Tags: <error>
Title: unserialize(): Error at offset 11218 of 25832 bytes in CRM_Core_BAO_Cache::getItem()
ThreadText: # unserialize(): Error at offset 11218 of 25832 bytes in CRM_Core_BAO_Cache::getItem()
  
  (Asked by: username_0 on 2016-10-13)
  
  First of all, thank you for the support. I hope I can help anybody sometime!
  
  I have Civicrm 4.7.12 installed in Drupal 7.51, and sometimes I get the error:
  Notice: unserialize(): Error at offset X of Y bytes en CRM\_Core\_BAO\_Cache::getItem() (X and Y are integer values)
  
  It begun after I upgraded to Civicrm 4.7.11, and no matter what I test... I can't resolve it.
  
  Can anybody help me?
  Thanks a million!
  
  **Tags:** error
  
  > **Comments:**
  > **username_1**: Welcome to StackExchange! It would be helpful if you could say what you are doing when you get this error.  
  > **username_0**: Hi Again. It shows at different points. For example, when I search a contact, or at "New mailing". Apparently Civicrm works well, but It shows these messages...  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_2 on 2016-10-18. Score: 2
  
  I just got this happening also, on a 4.6 install. It's due to an issue with your civicrm\_settings table. That piece of code you reference is pulling out settings type values from that table and caching them. The code assumes that the values in there are objects or arrays and have to get serialized and unserialized as they get stuffed in and pulled out of text fields. The error is due to the code's inability to unserialize the value, which can happen if it gets serialized badly, or was never serialized in the first place.
  
  In your case, it looks like it's really big and exceeds the space available (since it's pulling out 24K bytes from that poor little field). In my case, there was some non-serialized data in there, possibly from a previous code version.
  
  All I did to fix it was to look through my civicrm\_settings table and saw a lot of entries for the name 'navigation' with a non-serialized string, and removed them (they were in the Personal Preferences group and were all the same, so it seemed innocuous).
  
  For your case, you could find all the entries with a value length bigger than 20K and it'll probably be evident.
  
  I suspect you might be misusing one of your fields/features.
  
  > **Comments:**
  > **username_3**: I've seen the same happen when a similar CMS table (Drupal's "variable" table) was being misused as a cache. (I've also seen a CiviCRM site inject identical "navigation" values for each user, all with the same eight-character  string, into the settings table. username_2 did your "navigation" setting strings all start with "X5S"?  
  > **username_2**: They were all "sMtgpUbb". And they had recent but not identical 'created_date' values, so I suspect it's a current code issue. But I've only seen it on one site so far, so there might be only specific circumstances that apply. In general, whenever we're stuffing serialized objects/arrays into string fields, we're likely to hit limits at some point, so some kind of size checking might be a good idea. On the other hand, cache get/put operations are not places you want to be adding too much overhead.  
  > **username_3**: Thanks. Yeah all this site's 'navigation' strings were an eight-char random-looking-but-identical string. Glad to know at least one other person has seen this weirdness :D  
  > **username_3**: [`CRM_Core_BAO_Navigation::resetNavigation()`](https://github.com/civicrm/civicrm-core/blob/master/CRM/Core/BAO/Navigation.php#L683) username_2, in case you were intrigued ... see also [735386975](https://github.com/civicrm/civicrm-core/commit/7353869752836eeff00ab68234f0d64303cfd713) and [CRM-12337](https://issues.civicrm.org/jira/browse/CRM-12337). In combination with DB logging and a large number of contacts, `log_civicrm_setting` starts to get ... large :)  
  > **username_0**: username_2 and username_3, thank you very much! I'll check everything and post the results.  
  > **username_0**: Hi again, I tried to look for entries with length=25832 at civicrm_setting with no results, but there was at civicrm_cache table. Looking at the group_name and path, corresponds to "contact fields" and "importableFields All_0_0_0_1".  
  > **username_2**: That 25832 number is probably too specific, just look for big ones. Anything bigger than 10K is likely something gone bad.  re: misusing fields/features, I'm going to hazard a guess that you put too much data into a custom field.  
  
  ---
  
  