[ICQ/AIM] Possibly fix for broken privacy lists in some accounts (tickets #9034, #12549)
D. Gathmann
dzlists at arcor.de
Sun Oct 10 20:27:22 EDT 2010
(Related to tickets #9034, #12549 and fix
http://developer.pidgin.im/viewmtn/revision/info/46797f86bb26f4b4c73cd408387c3f5ca9caccca)
Hello,
I have got (since I don't know when) the problem with broken privacy lists
on one of my ICQ accounts, as mentioned by others in ticket #9034.
("Unable to add the buddy <...> for an unknown reason." messsage when
trying to add someone to the invisible or ignore list.)
After some playing with privacy lists in pidgin 2.7.4devel, including
switching between several versions of pidgin and other clients, also a test
account broke, so I tried to understand what was happening there.
I've added some lines to oscar/family_feedbag.c to compare the contents of
the ssi_itemlist in broken and sane accounts.
The content of od->ssi.local is dumped to the debug console each time
before and after an item is added to a private list.
I did this for two working (#2, #3) and two non-working (#1, #4) accounts:
--- broken #1 -------
(00:24:14) oscar: ssi: About to add a deny
(00:24:14) dump: gid=0x0000 bid=0x0000 list_type=0x0001 name='(null)'
(00:24:14) dump: gid=0x0000 bid=0x0001 list_type=0x0004 name='(null)'
(00:24:14) dump: gid=0x0000 bid=0x0002 list_type=0x0005 name='(null)'
(00:24:14) dump: gid=0x0000 bid=0x0003 list_type=0x0014 name='1'
(00:24:14) dump: gid=0x0000 bid=0x0004 list_type=0x001d name='(null)'
(00:24:14) dump: gid=0x0000 bid=0x0007 list_type=0x0029 name='facebook'
(00:24:14) dump: gid=0x0000 bid=0x0010 list_type=0x0020 name='ICQ-MDIR'
(00:24:14) dump: gid=0x0000 bid=0x0013 list_type=0x0028 name='(null)'
(00:24:14) dump: gid=0x0001 bid=0x0000 list_type=0x0001 name='Buddys'
(00:24:14) dump: gid=0x0001 bid=0x0001 list_type=0x0000 name='222222222'
(00:24:14) dump: gid=0x0001 bid=0x0002 list_type=0x0000 name='444444444'
(00:24:14) dump: gid=0x0001 bid=0x0003 list_type=0x0000 name='333333333'
(00:24:14) dump: gid=0x0002 bid=0x0000 list_type=0x0001 name='Buddies'
(00:24:14) aim_ssi_add_to_private_list: adding 333333333 to list_type 0x000e for ssi.local 0x0a5aca48
(00:24:14) dump: gid=0x0000 bid=0x0000 list_type=0x0001 name='(null)'
(00:24:14) dump: gid=0x0000 bid=0x0001 list_type=0x0004 name='(null)'
(00:24:14) dump: gid=0x0000 bid=0x0002 list_type=0x0005 name='(null)'
(00:24:14) dump: gid=0x0000 bid=0x0003 list_type=0x0014 name='1'
(00:24:14) dump: gid=0x0000 bid=0x0004 list_type=0x001d name='(null)'
(00:24:14) dump: gid=0x0000 bid=0x0005 list_type=0x000e name='333333333' <<<
(00:24:14) dump: gid=0x0000 bid=0x0007 list_type=0x0029 name='facebook'
(00:24:14) dump: gid=0x0000 bid=0x0010 list_type=0x0020 name='ICQ-MDIR'
(00:24:14) dump: gid=0x0000 bid=0x0013 list_type=0x0028 name='(null)'
(00:24:14) dump: gid=0x0001 bid=0x0000 list_type=0x0001 name='Buddys'
(00:24:14) dump: gid=0x0001 bid=0x0001 list_type=0x0000 name='222222222'
(00:24:14) dump: gid=0x0001 bid=0x0002 list_type=0x0000 name='444444444'
(00:24:14) dump: gid=0x0001 bid=0x0003 list_type=0x0000 name='333333333'
(00:24:14) dump: gid=0x0002 bid=0x0000 list_type=0x0001 name='Buddies'
(00:24:14) oscar: ssi: status is 0x0003 for a 0x0008 action with name no item
(00:24:14) oscar: ssi: Action 0x0008 was unsuccessful with error 0x0003
--- sane #2 --------
(00:17:34) oscar: ssi: About to add a deny
(00:17:34) dump: gid=0x0000 bid=0x0000 list_type=0x0001 name='(null)'
(00:17:34) dump: gid=0x0000 bid=0x0001 list_type=0x0004 name='(null)'
(00:17:34) dump: gid=0x0000 bid=0x0002 list_type=0x0005 name='(null)'
(00:17:34) dump: gid=0x0000 bid=0x0003 list_type=0x0020 name='ICQ-MDIR'
(00:17:34) dump: gid=0x0000 bid=0x0004 list_type=0x0014 name='1'
(00:17:34) dump: gid=0x0000 bid=0x0005 list_type=0x001d name='(null)'
(00:17:34) dump: gid=0x0001 bid=0x0000 list_type=0x0001 name='Buddys'
(00:17:34) dump: gid=0x0001 bid=0x0001 list_type=0x0000 name='333333333'
(00:17:34) dump: gid=0x0001 bid=0x0002 list_type=0x0000 name='111111111'
(00:17:34) aim_ssi_add_to_private_list: adding 111111111 to list_type 0x000e for ssi.local 0x0a67d610
(00:17:34) dump: gid=0x0000 bid=0x0000 list_type=0x0001 name='(null)'
(00:17:34) dump: gid=0x0000 bid=0x0001 list_type=0x0004 name='(null)'
(00:17:34) dump: gid=0x0000 bid=0x0002 list_type=0x0005 name='(null)'
(00:17:34) dump: gid=0x0000 bid=0x0003 list_type=0x0020 name='ICQ-MDIR'
(00:17:34) dump: gid=0x0000 bid=0x0004 list_type=0x0014 name='1'
(00:17:34) dump: gid=0x0000 bid=0x0005 list_type=0x001d name='(null)'
(00:17:34) dump: gid=0x0000 bid=0x0006 list_type=0x000e name='111111111' <<<
(00:17:34) dump: gid=0x0001 bid=0x0000 list_type=0x0001 name='Buddys'
(00:17:34) dump: gid=0x0001 bid=0x0001 list_type=0x0000 name='333333333'
(00:17:34) dump: gid=0x0001 bid=0x0002 list_type=0x0000 name='111111111'
(00:17:35) oscar: ssi: status is 0x0000 for a 0x0008 action with name 111111111
So in #2, the blocking entry (list_type=0x000e) gets bid 0x0006, above the general(?)
entries with bids 0x0000 to 0x0005.
In case #1, the entry is inserted with bid 0x0005, in a gap between the general entries.
However #3 works with one general entry greater than the blocking entry:
--- sane #3 --------
(00:31:06) oscar: ssi: About to add a deny
[..]
(00:31:06) aim_ssi_add_to_private_list: adding 111111111 to list_type 0x000e for ssi.local 0x0a856ae0
(00:31:06) dump: gid=0x0000 bid=0x0000 list_type=0x0001 name='(null)'
(00:31:06) dump: gid=0x0000 bid=0x0001 list_type=0x001d name='(null)'
(00:31:06) dump: gid=0x0000 bid=0x0002 list_type=0x0004 name='(null)'
(00:31:06) dump: gid=0x0000 bid=0x0003 list_type=0x0020 name='ICQ-MDIR'
(00:31:06) dump: gid=0x0000 bid=0x0004 list_type=0x0014 name='1'
(00:31:06) dump: gid=0x0000 bid=0x0005 list_type=0x0029 name='facebook'
(00:31:06) dump: gid=0x0000 bid=0x0006 list_type=0x000e name='111111111' <<<
(00:31:06) dump: gid=0x0000 bid=0x0007 list_type=0x0005 name='(null)'
(00:31:06) dump: gid=0x0000 bid=0x0009 list_type=0x0019 name='ooooooooo'
[..]
(00:31:06) dump: gid=0x0001 bid=0x0000 list_type=0x0001 name='Buddys'
(00:31:06) dump: gid=0x0001 bid=0x0001 list_type=0x0000 name='222222222'
(00:31:06) dump: gid=0x0001 bid=0x0002 list_type=0x0000 name='111111111'
(00:31:06) dump: gid=0x0002 bid=0x0000 list_type=0x0001 name='self'
(00:31:06) dump: gid=0x0002 bid=0x0001 list_type=0x0000 name='444444444'
[..]
(00:31:06) oscar: ssi: status is 0x0000 for a 0x0008 action with name 111111111
--- broken #4 -------
(00:29:50) oscar: ssi: About to add a deny
[..]
(00:29:50) aim_ssi_add_to_private_list: adding 111111111 to list_type 0x000e for ssi.local 0x0a53cb70
(00:29:50) dump: gid=0x0000 bid=0x0000 list_type=0x0001 name='(null)'
(00:29:50) dump: gid=0x0000 bid=0x0001 list_type=0x0005 name='(null)'
(00:29:50) dump: gid=0x0000 bid=0x0002 list_type=0x0020 name='ICQ-MDIR'
(00:29:50) dump: gid=0x0000 bid=0x0003 list_type=0x0004 name='(null)'
(00:29:50) dump: gid=0x0000 bid=0x0004 list_type=0x0015 name='(null)'
(00:29:50) dump: gid=0x0000 bid=0x0005 list_type=0x001d name='(null)'
(00:29:50) dump: gid=0x0000 bid=0x0006 list_type=0x000e name='111111111' <<<
(00:29:50) dump: gid=0x0000 bid=0x0008 list_type=0x0019 name='ooooooooo'
(00:29:50) dump: gid=0x0000 bid=0x0016 list_type=0x0029 name='facebook'
(00:29:50) dump: gid=0x0000 bid=0x6eae list_type=0x0014 name='1'
(00:29:50) dump: gid=0x0001 bid=0x0000 list_type=0x0001 name='Buddys'
(00:29:50) dump: gid=0x0001 bid=0x0001 list_type=0x0000 name='111111111'
(00:29:50) dump: gid=0x0001 bid=0x3681 list_type=0x0000 name='444444444'
[..]
(00:29:50) dump: gid=0x0004 bid=0x0000 list_type=0x0001 name='self'
(00:29:50) dump: gid=0x0004 bid=0x14a0 list_type=0x0000 name='222222222'
(00:29:51) oscar: ssi: status is 0x0003 for a 0x0008 action with name no item
(00:29:51) oscar: ssi: Action 0x0008 was unsuccessful with error 0x0003
The problem does not occur when using other clients (Miranda, ICQ 7.1, qip 2010).
These generate some kind of hashed or pseudo-random bid numbers instead of ascending numbers:
--- broken #1, but entries can be added with e.g. Miranda -------
(01:40:27) dump: gid=0x0000 bid=0x0000 list_type=0x0001 name='(null)'
(01:40:27) dump: gid=0x0000 bid=0x0001 list_type=0x0004 name='(null)'
(01:40:27) dump: gid=0x0000 bid=0x0002 list_type=0x0005 name='(null)'
(01:40:27) dump: gid=0x0000 bid=0x0003 list_type=0x0014 name='1'
(01:40:27) dump: gid=0x0000 bid=0x0004 list_type=0x001d name='(null)'
(01:40:27) dump: gid=0x0000 bid=0x0007 list_type=0x0029 name='facebook'
(01:40:27) dump: gid=0x0000 bid=0x0010 list_type=0x0020 name='ICQ-MDIR'
(01:40:27) dump: gid=0x0000 bid=0x0013 list_type=0x0028 name='(null)'
(01:40:27) dump: gid=0x0000 bid=0x2180 list_type=0x0003 name='444444444' <<<
(01:40:27) dump: gid=0x0000 bid=0x21e2 list_type=0x0003 name='333333333' <<<
(01:40:27) dump: gid=0x0000 bid=0x7d8c list_type=0x0003 name='222222222' <<<
(01:40:27) dump: gid=0x0001 bid=0x0000 list_type=0x0001 name='Buddys'
(01:40:27) dump: gid=0x0001 bid=0x0001 list_type=0x0000 name='222222222'
(01:40:27) dump: gid=0x0001 bid=0x0002 list_type=0x0000 name='444444444'
(01:40:27) dump: gid=0x0001 bid=0x0003 list_type=0x0000 name='333333333'
(01:40:27) dump: gid=0x0001 bid=0x4433 list_type=0x0000 name='111111111'
(01:40:27) dump: gid=0x0002 bid=0x0000 list_type=0x0001 name='Buddies'
[..]
It turned out the broken accounts work when starting entries with a higher bid number, i.e.
bid=0x0006 for #1 and bid=0x0007 for #4.
My somewhat naive guess is that a range of low bid numbers is reserved for general entries.
The range limit is wrong because some entries are outside the range, e.g.
gid=0x0000 bid=0x0007 list_type=0x0029 name='facebook'.
I'm not sure whether this solves the problem, but I think it's pretty close. :-)
Regards,
Dustin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: my_ssi_itemlist_dump.c
Type: text/x-csrc
Size: 555 bytes
Desc: not available
URL: <http://pidgin.im/pipermail/devel/attachments/20101011/504d6509/attachment-0002.c>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: family_feedbag.c.diff
Type: text/x-patch
Size: 450 bytes
Desc: not available
URL: <http://pidgin.im/pipermail/devel/attachments/20101011/504d6509/attachment-0002.bin>
More information about the Devel
mailing list