Pidgin crashes on startup, deleting state doesn't help

[Sesivany]

I've experienced another crash on startup (v1.2.4), but it seems different than the last one I reported. It quits with this output:
pidgin: structures.c:83: tree_insert_peer_by_name: Assumption „c“ not satisfied.

Here is a backtrace and other logs: https://bugzilla.redhat.com/show_bug.cgi?id=1297787

Deleting the "state" file doesn't help like with the previous crash on startup.

I'm attaching a debug log.
debug.txt

[BenWiederhake]

Sounds like you have two peers with the same name (print_name), or there's some other weird stuff happening.

[majn]

Your own user name is somehow inserted twice, it would be interesting to know how it was created for the first time. Can you apply this diff on 1.2.4 and try to see if you can get another log of the crash?

printf.diff.txt

[EionRobb]

Just wanted to chip in to say that #220 is very similar, that the tree map algorithm of tgl can't handle duplicate values. I'm hoping that testing to allow duplicates in the tree will help kill that issue as well as this one (testing still in progress)

[BenWiederhake]

Why would allowing duplicates ever be a good idea? The core issue is that something inserts the same value twice. In the case of queries, it's the query ID; in this case, it seems to be the print_name.

If that happens, the tree can't behave "correctly". I mean, how should it behave? Let's say the alarm for query #123 goes off. Which query should the tree return? Recall that the arguments from the alarm only fit to one of the queries, not both.

[majn]

I suspect that this is most likely some issue with generating namens, duplications shouldn't occur in the tree and need to be fixed.

[Sesivany]

After turning on the computer today, I cannot reproduce it any more. If it occurs again, I'll try to apply the diff and report results.

[zesaver]

Have the same issue, few times a day.

[p91paul]

I can always reproduce this issue when starting pidgin with -d. I bet it has to do with concurrency. Are you loading users asynchronously? I think this part of the output is relevant:

(22:22:07) blist: Updating buddy status for <user> (Telegram)
(22:22:07) prpl-telegram: update 0x9961fd5c (check=-1)
(22:22:07) prpl-telegram: update_on_ready(): The account is done fetching new history
(22:22:07) g_log: (telegram-purple.c:517):update_on_ready: runtime check failed: (P)

This is not at the end of the debug output, but what I see when I start pidgin is that as soon as that user appears in the buddy list pidgin crashes. That user is the last one I chatted with. If users are loading in different threads, then maybe one failing actually kills pidgin, while the others continue to clutter the debug output.

[BenWiederhake]

@p91paul: Please file this as a separate issue, as it's crashing for a different reason.

Also, please do post the messages after this; the runtime check is only a "warning", and does not crash anything. Also, pidgin effectively disallows multi-threading.

[p91paul]

I believe it's the same issue, since the same messages appear at some point in @Sesivany log. They might be unrelated with the crash though. I'll post a full log ASAP.

[SwooshyCueb]

Having the same issue with dev-1.3.0, whenever I try to start pidgin, every time

pidgin: structures.c:83: tree_insert_peer_by_name: Assertion `c' failed.
fish: “pidgin” terminated by signal SIGABRT (Abort)

Deleting state does nothing.

I do not have this issue with the master branch.

[BenWiederhake]

The error comes when two users (truly two diferent users!) have the same name. The error occurs when the "second" user gets inserted in the name→peer lookup tree. Here are the relevant lines:

#define peer_cmp_name(a,b) (strcmp (a->print_name, b->print_name))

DEFINE_TREE(peer_by_name,tgl_peer_t *,peer_cmp_name,0)

Temporary workaround : Use another client (e.g. webogram) to change the alias of one of the people. To find the current culprit, just look at the debug output, e.g., pidgin -d for pidgin.

Long-term workaround: no idea. A clean fix would be to convert the tree into a "multiset"-tree, so it can return multiple proposals when the users looks up a name (or whatever this tree is used for). A dirty fix could just choose to not update the tree if the name is already there. Are there better options?

EDIT: Credit goes to Javier, who was able to send me a log. That's why we always ask for logs! ;)

[BenWiederhake]

I still can't reproduce this issue. Please send me invitations to large groups where you think the name collisions happen..

[SwooshyCueb]

https://telegram.me/joinchat/BQZd7gmSs1W2FK-SAnaO2g
I have been unable to track down where the name collisions are coming from, so I just created a TG account with my other number so I could create a group myself. Happy bug-squashing.

[BenWiederhake]

@SwooshyCueb: Works indeed, but it needs to be an actual "phonebook contact", which is why I couldn't reproduce it so easily. This kind of raises the question why so many people have identically named phonebook contacts, but tgp obviously should work even in that case.

[SwooshyCueb]

In that case, I think a different set of circumstances is what's causing the assertion failure for me. I do not currently have any phonebook contacts with the same name.

[ssibb]

hi! same problem here.

1. i created a group using the telegram android app, and i made it as a supergroup. It was named gugo. After playing around, it appeared as gugo Use of OpenSSL is GPL-incompatible #1 (not sure why, i was just trying how supergroup works on android). Then i deleted the supergroup from my android phone and also from the other phone. It was a private group (this was the link https://telegram.me/joinchat/DojI1EBTSUOk2HuwLk6EUg but it doesn't work anymore as i deleted the supergroup).
   Now every time i open pidgin, i've got a crash. Here the last few lines of pidgin -d

(09:39:38) prpl-telegram: resolving duplicate for Gugo, assigning: Gugo #1
(09:39:38) prpl-telegram: update_chat_handler() (CREATED PHOTO FLAGS TITLE)
(09:39:38) prpl-telegram: Already downloaded
(09:39:38) g_log: tgp_info_load_photo_done: assertion `C' failed
(09:39:38) prpl-telegram: update_user_handler() (CREATED PHONE PHOTO NAME FLAGS ACCESS_HASH)
(09:39:38) prpl-telegram: new user Telegram allocated (CREATED OFFICIAL )

please note that i cannot use the web.telegram workaround as the invitation link has expired!

Result: {"_":"rpc_error","error_code":400,"error_message":"INVITE_HASH_EXPIRED"}

any idea of where i can delete the ghost supergroup "Gugo"??? thanks

EDIT: i forgot to mention that i've already tried to delete auth and status files...i've also edited the blist.xml removing the group, without any luck...