Closed acli closed 7 years ago
Backtrace? Debug log?
Reenabling the haself check hasn’t caused the crash to reappear, so somehow pidgin seems to be remembering which chats have been ignored. I’ll try to set up a new renamed chat and when it crashes I’ll email you the logs.
Actually I do have an old debug log from before I patched the prpl, but I don’t have a gdb trace. I’ll have a new set when a new chat is set up and causes a crash.
The debug log doesn't seem to have anything like a crash, it looks like it exits normally unloading everything properly.
I can't reproduce the bug by renaming a chat.
What distro? You might already have something that catches crashes, for example coredumpctl in systemd based distros, apport in earlier ubuntu, abrt in fedora.
Hmm. Maybe it didn’t crash the prpl then. Let me rename the bug. This is Ubuntu 15.10.
Okay, JnNy from #bitlbee provided a proper debug log for an issue that seems to be equivalent to this.
It's not "renamed" as in "changed the topic", it's "renamed" as in "kicked out of the old one and created a new one", so now i can reproduce this.
The result is that the thread information is queried when attempting to join, and the reply doesn't have self in all_participants
, as the first post of this ticket suggests. This should be a non-fatal join error, not a connection error.
{
"[...]": {
"all_participant_ids": null,
"all_participants": ["..."],
"can_viewer_reply": false,
"cannot_reply_reason": "VIEWER_NOT_SUBSCRIBED",
"customization_info": null,
"delivery_receipts": ["..."],
"ephemeral_ttl_mode": 0,
"folder": "INBOX",
"former_participant_ids": null,
"former_participants": ["..."],
"has_viewer_archived": false,
"id": "[...]",
"image": {
"uri": "[...]"
},
"is_group_thread": true,
"is_viewer_subscribed": false,
"last_message": {
"nodes": [
{
"__type__": {
"name": "ParticipantLeftMessage"
},
"message_sender": {
"email": "[...]",
"messaging_actor": {
"__type__": {
"name": "User"
},
"id": "[...]",
"name": "[...]"
}
},
"snippet": "[...] removed you from the group."
}
]
},
"messages": null,
"mute_until": -1,
"name": "[...]",
"read_receipts": ["..."],
"thread_key": {
"other_user_id": null,
"thread_fbid": "[...]"
},
"unread_count": 0,
"updated_time_precise": "[...]"
}
}
(note to self: full log in dir=rupiah)
This is fixed in 0.9.5
https://github.com/dequis/purple-facebook/releases/tag/v0.9.5-9ff9acf9fa14
The prpl (version 66ee77378d82 in git) appears to be not handling renamed chats correctly. If the user is in a group chat that is renamed, the prpl crashes soon after login with a “Failed to parse thread information” error and the facebook account is disconnected (cf. #214 ).
If the “|| !haself” check in api.c (what causes fb_api_thread_parse to return the FALSE which is interpreted as “Failed to parse thread information”) is commented out, the prpl doesn’t crash but the renamed chats are not loaded.
This suggests that “haself” is probably not the correct condition to check for and something else is missing which is causing named group chats to be not recognized as chats the user is participating in.
104 suggests that this might be a regression.