Closed Bug 954402 Opened 7 years ago Closed 7 years ago

Friends shown offline in buddylist when are in fact, online.


(Instantbird :: Contacts window, defect)

Not set


(Not tracked)



(Reporter: bugzilla, Assigned: florian)




(1 file)

*** Original post on bio 968 by Michael <Prescience500 AT> at 2011-08-09 22:01:00 UTC ***

*** Due to BzAPI limitations, the initial description is in comment 1 ***
*** Original post on bio 968 as attmnt 774 by Prescience500 AT at 2011-08-09 22:01:00 UTC ***

I have a friend (possibly many) who are shown as offline when they are actually online via Google Talk. If I open an IM window, however, they are shown accurately as being online in that IM window. If I open up Gmail, Gmail also accurately shows the person as being online. To my knowledge this only effects my one friend, but could effect many of them.

Unfortunately, I've no idea how to duplicate this, but to my knowledge, the friend always appears this way in the buddylist, at least it has for some time.
Duplicate of this bug: 954525
*** Original post on bio 968 at 2011-10-21 02:26:57 UTC ***

We've had another report of this, confirming. (Note that both were with Google Talk, not sure if that matters.)
Ever confirmed: true
*** Original post on bio 968 by Michael <Prescience500 AT> at 2011-10-21 02:39:02 UTC ***

I was actually able to fix this by deleting all of Instantbird's files in my Home directory (rather than searching around to figure out which file/s are responsible for the buddylist.) Then, I reopened Instantbird, readded all of my accounts, and reconfigured it. After that, her screenname was properly showing in my buddylist. I havn't had the problem since except for an AOL buddy who i never talk to who appears on my Google Talk list for a bit whenever i first sign on, but goes away after a certain period of time. The same happens on gmail and kopete though so I suspect this later one is caused by AOL's XMPP gateway.
*** Original post on bio 968 by impz <instantbirdbugs AT> at 2011-11-18 11:05:34 UTC ***

I had this bug on Win7 it appears to be caused by duplicate entries in the blist.sqlite database on the buddies table.  There were duplicate entries for my contact (also google talk - still not sure if this is a conincidence however!).  

I did the following
* Quit out of instantbird
* Backed up the database blist.sqlite in case of making a mistake
* Used the sqlitebrowser app to remove the duplicate entry
* Saved the database and quit the app
* Started instantbird

Problem solved.

I haven't time to look at the code but I'm guessing the resolution to this is either to make the "key" column into a column that requires a unique key so inserts fail (I don't know if sqlite supports this) or doing this in the code itself so that duplicate entries do not get created in the first place.
*** Original post on bio 968 at 2011-11-18 11:25:30 UTC ***

(In reply to comment #4)
> I had this bug on Win7 it appears to be caused by duplicate entries in the
> blist.sqlite database on the buddies table.  There were duplicate entries for
> my contact (also google talk - still not sure if this is a conincidence
> however!).  

What do you call "duplicate entries"? Can you give an example?
*** Original post on bio 968 by impz <instantbirdbugs AT> at 2011-11-18 11:46:22 UTC ***

The two rows from the original table are as follows.  I have changed the contact's name for privacy reasons but otherwise it is the same.

id	key			name	srv_alias	position		icon	contact_id
2		0		2
52		1		2
*** Original post on bio 968 at 2011-11-18 13:18:52 UTC ***

(In reply to comment #6)

This isn't necessarily a bug. Fred could be using the same address as an msn address and a Jabber id. Or it's possible you have configured a Google Talk account and an XMPP account, with Fred in the contact list of both of these accounts.

To find duplicates, you would need to join the buddies table with the account_buddy table and the accounts table, with a query looking a bit like this:

SELECT, b.key, a.prpl from buddies b JOIN account_buddy ab ON buddy_id = JOIN accounts a ON account_id = GROUP BY;

This query lists buddy ids, buddy keys and the associated protocol ids. If you find several buddy ids for the same buddy key and buddy protocol, there's something corrupted in your blist.sqlite database and we need to figure out why. If not, then you are corrupting it by removing things from it.
*** Original post on bio 968 by impz <instantbirdbugs AT> at 2011-11-18 15:36:46 UTC ***

I ran this query and it returns two rows for Fred.
id	key	prpl
2		prpl-gtalk
52		prpl-gtalk

I also ran this which seems to return three rows for buddy_id==2

select * from account_buddy where buddy_id in (2,52);

account_id	buddy_id		status	tag_id
1		2			1
1		2			1
1		2			1
1		52			1

I have two genuine gtalk accounts Fred only appears in one of them (according to the official google talk client).

I'm pretty sure I did not set up the account (that Fred) appears in twice once with XMPP and once with gtalk.  If I did I would expect to find all the other buddies for this account duplicated which is not the case, this is the only one.
*** Original post on bio 968 at 2011-11-18 15:58:03 UTC ***

Several entries in the account_buddy table for the same buddy of the same account can be OK if they are associated with different tags, but this doesn't seem to be the case in your example.

It seems you have some real database corruption :-/. Which version of Instantbird are you running? Which versions have you used in the past on the same profile? Do you have any idea of what could have happened for this profile to get corrupted?
*** Original post on bio 968 by impz <instantbirdbugs AT> at 2011-11-18 16:11:06 UTC ***

I am running "version 1.1 (20111014141651)" Previously ran 1.0 and a version prior to that.

I don't know what the cause is.  Fred is a contact who I IM fairly frequently.

Maybe you don't need to know what the cause is here to prevent it, though.  As long as the database is in proper "first normal form" I think this can be avoided by keying the tables so that duplicates are not possible.
*** Original post on bio 968 at 2011-11-18 17:45:52 UTC ***

So you have never used a nightly build, or a potentially broken testing build?
Are you on Linux like the initial reporter?

I guess I could manually corrupt a testing profile with data similar to what you have described you have, and see what happens/fix the bad behaviors this causes.
This would ensure that people who have suffered from this bug already get back to a stable situation.

We could probably force SQLite to reject the duplicates, but that's only moving the problem. There's most likely some code somewhere that doesn't behave as expected in a specific and rare case. It would be great to find and fix it.

Anyway, thanks for the information you added in this bug! :)
Severity: normal → major
*** Original post on bio 968 at 2011-11-23 04:44:48 UTC ***

(Hopefully?) fixed in
Assignee: nobody → florian
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → 1.2
*** Original post on bio 968 at 2011-11-23 11:14:08 UTC ***

Some explanation for the changes I made in that changeset:

Yesterday while working on bug 954603 (bio 1171), I had at some point a broken protocol plugin implementation that caused this duplication of account_buddy entries to happen, so it was a good opportunity to debug this.

The first thing I did was adding a check for duplicates in the code that inserts account_buddy entries in the database. In case of a duplicate, this code will now write a descriptive error message in the Error Console, and return without writing to the database.

Second, while loading the database at startup, the code will now detect duplicate, and not attempt to create AccountBuddy objects for them. Instead it will write a descriptive error message to the Error Console, and just ignore the redundant entries.

Finally, I noticed another case that could cause the status of contacts in the contacts window to not be updated: if a (broken) protocol plugin has duplicated AccountBuddy instances for the same buddy and account, and send updates only to the most recently created one, these updates will be ignored by the contact list which listens only for updates on the first AccountBuddy it heard about for that buddy and account. I changed the contact list code to no longer ignore notifications in that case.

Note: I don't understand how you it would be possible to have duplicated entries in the buddies table, as there's a check right before the insertion. For now, I'll assume that the duplicates that have been reported there were caused by an older version of Instantbird.

Summary: I improved the code handling contacts to be more resistant to bugs in protocol plugin implementations. I think these changes will fix the bug reported here.
You need to log in before you can comment on or make changes to this bug.