GNOME Bugzilla – Bug 658573
Some contact in buddy list are shown as "empty"
Last modified: 2011-09-12 20:39:09 UTC
Created attachment 196000 [details] The "good" entry in CL is online, the other two empty entries can be shown as offline. This is a result of Bug #657914, after the fix contacts are shown as empty instead of segfaulting. Attached there are some screenshots, the situation is the following: Contact "Leonardo" appears 3 times in my CL, the first one is the real one, with 4 contact linked. It's clear from the attachments what info have been concealed and what are actually missing/empty spaces. The other two Leonardos in CL are "empty", the second attach shows what I mean with it. As per Bug #657914, those are the result of empathy_contact_dup_from_folks_individual() not being able to return a contact. The bug is actually somewhere else, folks most probably but I had not time to investigate further. It happens quite a lot. Using Debian's libfolks 0.6.1-1 and empathy 3.1.90.1-1. Some more info which might be useful, but probably pretty obvious: Contact Leonardo is among my favourites, thus the other empty-Leonardos appears in my favourite list as well. If I try to click on the empty contact as I wanted to chat with it, no chat windows opens. Attach there is also the contextual menu from one of the empty contacts.
Created attachment 196001 [details] info pop up for one of the empty entry. the other one is the same
Created attachment 196002 [details] contectual menu for an emtpy entry
Probably a folks issue yeah. When you experience this bug, could you please try to get some info from "folks-inspect" to see what's in Folks? You can use the "individuals" and "personas" commands to get a bump from folks.
Created attachment 196089 [details] folks-inspect individuals output There are two individuals with the same name. One with 6 personas and one with 1. The one with one has an ICQ uin, valid as far as I can see. The one with 6, as 3 valid IDs. There is another (fourth) valid ID not shown but counted (AFAIS), and *should* be OK, since it's (if I'm correct) from an jabber server not syndicated, so I sent a request by mistake he could never receive from this account I never removed it. Consider it as "sent but not accepted". And indeed Empathy counts 4 contact linked, it might make sense until here. The two left are *probably* the two empty contacts shown above. Not sure, though.
Created attachment 196090 [details] folks-inspect personas output Here it shows 4 valid personas, which should be the 4 counted in Empathy and referred in the "individuals" output comment. It seems OK, no sign of other empty items under the same alias.
The problem once shown, happened always (100%) with Empathy 3.1.90 in Debian experimental. Today I updated to 3.1.91 and the empty contacts disappered from CL, but they still are aruond, since folks-inspect still shows them.
I actually don't know why in Attachment #196089 [details] the 1-item individual with a single UIN is there, since the same UIN is included in the second individual (6-items one). Maybe this is normal or not related to this bug, but it is worth mentioning it, since it wasn't clear it's actually the same UIN in both individuals.
(In reply to comment #6) > The problem once shown, happened always (100%) with Empathy 3.1.90 in Debian > experimental. > Today I updated to 3.1.91 and the empty contacts disappered from CL, but they > still are aruond, since folks-inspect still shows them. Could be because your fix for bug #657914 has been included in 3.1.91.
I managed to reproduce this with not all the time. It seems to happen only with contacts having at least 3 or 4 personas linked.
I think I got it! Empathy is keeping a FolksIndividual.id -> FolksIndividual hash table, with the ID borrowed (ie, not copied) from the FolksIndividual; which looks sane as the ID should be immutable. Except it's not! At some point Folks changes the ID to a *new* pointer pointing to a new string containing the same ID ! So Empathy's borrowed ID is not a valid pointer any more and everything is fucked. Folks people: any reason to not have this ID actually immutable? If there is, the doc should explicitely say it because that's pretty confusing. I observed this with folks master and Vala 0.13.4.
Looks like the ID is not immutable any more: http://git.gnome.org/browse/folks/tree/folks/individual.vala#n1916
Created attachment 196255 [details] [review] individual-manager: dup the Individual ID instead of borrowing it It's not immutable any more so we have to copy the string.
Attachment 196255 [details] pushed as 5b8d540 - individual-manager: dup the Individual ID instead of borrowing it
(In reply to comment #10) > Folks people: any reason to not have this ID actually immutable? If there is, > the doc should explicitely say it because that's pretty confusing. The ID never actually was immutable, but it just happened to behave that way (because it always returned a const string from the first persona in the individual, which was effectively immutable). It would be nice to make the ID immutable, but that would mean that Empathy's linking dialogue could no longer build fake individuals by setting Individual.personas, for the purposes of working out what the individuals would look like in the UI (i.e. using the standard EmpathyIndividualWidget in the linking dialogue). I can't think of a better way of doing that at the moment, so I guess Individual.id has to remain mutable; and thus your patch is the right fix.