[Pidgin] #1937: Double-joining a chat causes the original client to hang/segfault

[Pidgin]

#1937: Double-joining a chat causes the original client to hang/segfault
------------------------------------------------------+---------------------
 Reporter:  serynth                                   |       Type:  defect
   Status:  new                                       |   Priority:  minor 
Component:  pidgin (gtk)                              |    Version:  2.0.2 
 Keywords:  AIM chat join twice segfault hang freeze  |    Pending:  0     
------------------------------------------------------+---------------------
 Okay, this will take some explaining. Note that the original copy of
 pidgin (pidgin1) was 2.0.1, as I had updated without restarting pidgin.

 While fooling with accounts, I opened a second copy of pidgin (now 2.0.2)
 with the config directory set to a duplicate of ~/.purple, ~/.purple2,
 that only lacked the logs directory. It automatically logged in (as I
 forgot to add the switch to start up as offline), and automatically joined
 the chat room I had asked it to auto-join. Which is, of course, the
 expected behavior. I set pidgin2 back to offline manually and closed the
 pidgin2 chat window.

 When I returned to the pidgin1 chat window, I noticed that it said I had
 left the room and only the two other participants were there. Out of
 curiosity I began typing, and pidgin1 froze when I tried to send the
 message. Eventually I gave up and switched to the terminal window
 supporting pidgin2, then kill -9'd pidgin1.

 I started it up again: pidgin3. pidgin3 auto-joined the chat room and
 everything ran fine. Out of curiosity, I started yet another copy:
 pidgin4. When I switched to pidgin3's chat window, which now reported that
 I had left, to send a test message, it failed to send the message (didn't
 appear in either chat window) and, when I attempted to type again, pidgin3
 died.

 Starting it up in gdb, I tried at least four times to get new instances to
 segfault the gdb one like they did pidgin3, the core file having
 mysteriously vanished. They couldn't even get pidgingdb to freeze. I would
 join the chat on pidgingdb, then start a new instance to join as well. The
 first three or so times, the pidgingdb window did not say that I had left
 the chat room, and sending any number of messages didn't hang the client.
 The messages, however, would not show up in the chat buffer on either
 window. Then I would close the pidgingdb chat window, kill the new
 instance, and start over.

 Finally I was successful when pidgingdb displayed my exit message in the
 chat room, and (coincidentally) the message I sent (from pidgingdb) was
 banging on the keyboard. I... can't say I can explain that one.

 Here's the backtrace. Each function call in the backtrace also includes a
 "No symbol table info available." after it. I stripped these out, as this
 description is long enough as it is.

 `#0  0x47830d1a in memcpy () from /lib/libc.so.6`[[BR]]`#1  0x436ff2e7 in
 purple_circ_buffer_append () from /usr/lib/libpurple.so.0`[[BR]]`#2
 0x00235e6e in flap_connection_send () from
 /usr/lib/purple-2/liboscar.so.0`[[BR]]`#3  0x0022447d in aim_chat_send_im
 () from /usr/lib/purple-2/liboscar.so.0`[[BR]]`#4  0x0023e1f0 in
 oscar_send_chat () from /usr/lib/purple-2/liboscar.so.0`[[BR]]`#5
 0x4372e9eb in serv_chat_send () from /usr/lib/libpurple.so.0`[[BR]]`#6
 0x43706304 in g_source_remove () from /usr/lib/libpurple.so.0`[[BR]]`#7
 0x0808e23d in ?? ()`[[BR]]`#8  0x47b190f9 in g_cclosure_marshal_VOID__VOID
 ()`[[BR]]`   from /lib/libgobject-2.0.so.0`[[BR]]`#9  0x47b0bd9b in
 g_closure_invoke () from /lib/libgobject-2.0.so.0`

 And so I bring an end to this unusually verbose description. Hopefully
 this is of assistance to you.

-- 
Ticket URL: <http://developer.pidgin.im/ticket/1937>
Pidgin <http://pidgin.im>
Pidgin