| Summary: | version == hash_table->version assertion failure when disposing the vCard manager | ||
|---|---|---|---|
| Product: | Telepathy | Reporter: | Guillaume Desmottes <guillaume.desmottes> |
| Component: | gabble | Assignee: | Telepathy bugs list <telepathy-bugs> |
| Status: | RESOLVED MOVED | QA Contact: | Telepathy bugs list <telepathy-bugs> |
| Severity: | normal | ||
| Priority: | medium | CC: | pedrogfrancisco, will |
| Version: | unspecified | ||
| Hardware: | Other | ||
| OS: | All | ||
| See Also: | https://bugzilla.redhat.com/show_bug.cgi?id=828797 | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
|
Description
Guillaume Desmottes
2012-02-02 04:26:09 UTC
Taking a look at this. The problem, in broad terms, is: #3 0xb70b8328 in g_hash_table_foreach (hash_table=0x993c808, func=0x8108e50 <disconnect_entry_foreach>, user_data=0x0) at disconnect_entry_foreach, in some situations, ultimately ends up calling g_hash_table_remove(), thereby modifying the table being iterated. I haven't figured out exactly what that situation is, yet. Can't figure out how to reproduce it, sorry.
This line in the backtrace:
#15 0x08098972 in connection_force_close_cb (source=0x9d0b560, res=0x9d236f0,
user_data=0x9910c10) at wocky-c2s-porter.c:1257
tells us that this was an unclean disconnection. My thinking was that we need a vcard cache entry with ->vcard_node, ->pipeline_item, and ->pending_requests to be NULL in order for the code in cache_entry_attempt_to_free() which modifies the hash table to fire, so I tried requesting a vCard, sending back an error of type='wait' to tell it to try again later, and then uncleanly disconnecting the connection in a variety of ways… but no dice.
I did make the surprising discovery that if I change connect/stream-closed.py to send a spurious stanza right before the </stream:stream>:
- # server closes its stream
+ # server tells us it hates us then closes the stream cleanly.
+ stream.send(
+ elem('message', from_='lol@localhost')(
+ elem('body')(u'piss off')
+ ))
stream.sendFooter()
then the test fails! Gabble never sends the corresponding </stream:stream>. The issue seems to be related to the state transitions of WockyXmppConnection at the end of a stream when it gets a blob of data containing both a stanza and the </stream:stream> — if you stick a q.expect('dbus-signal', signal='MessageReceived') before sendFooter(), the test passes. But I couldn't track it down further. :(
So I am donating these bugs back to the public domain.
On the launchpad report one of the users says: https://bugs.launchpad.net/ubuntu/+source/telepathy-gabble/+bug/915015/comments/17 "i can reproduce this bug. all i need is just switch off my internet or set offline status." This is still actual with the latest version of telepathy. No newer stacktrace is available(identification by apport on launchpad on stacktrace top). still affecting in ubuntu 13.04 with telepathy gabble 0.15.2-0ubuntu1 -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/telepathy/telepathy-gabble/issues/207. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.