[Pidgin] #8594: msn connection crash

[Pidgin]

#8594: msn connection crash
--------------------+-------------------------------------------------------
 Reporter:  plaes   |           Owner:  khc    
     Type:  defect  |          Status:  pending
Milestone:          |       Component:  MSN    
  Version:  2.5.5   |      Resolution:         
 Keywords:          |   Launchpad_bug:         
--------------------+-------------------------------------------------------
Changes (by plaes):

  * status:  pending => new


Comment:

 Replying to [comment:4 khc]:
 > can you get a debug log?

 Getting the debug log is a bit hard, because these crashes happen at
 random times often once every week... But I'll try...

 Also, when looking at the bug reports there are two patterns (so we might
 have actually two different issues here). Also, I'm using 2.5.5 tarball
 for the sources:

 * #8594 and #8664 - crash happens at line 511 in `soap.c`
 {{{
 [snip]
 507:        perrno = errno;
 508:        if (cnt < 0 && perrno != EAGAIN)
 509:                purple_debug_info("soap", "read: %s\n",
 g_strerror(perrno));
 510:
 511:        if (conn->current_request && conn->current_request->secure &&
 512:                !conn->unsafe_debug)
 513:                purple_debug_misc("soap", "Received secure
 request.\n");
 514:        else if (count != 0)
 515:                purple_debug_misc("soap", "current %s\n",
 conn->buf->str + cursor);
 [/snip]
 }}}
 Now when checking the locals in this function: ( #8594 / #8664 ):
  * perrno = 11 / 11 (EAGAIN error)
  * count = 0 / 0
  * cnt = 0 / ???
  * cursor = 13522224 / 0

 * #8797 and one of my last crashes happen at line 500 in `soap.c`
 {{{
 [snip]
 496:        if (conn->buf == NULL) {
 497:                conn->buf = g_string_new_len(buf, 0);
 498:        }
 499:
 500:        cursor = conn->buf->len;
 501:        while ((cnt = purple_ssl_read(conn->ssl, buf, sizeof(buf))) >
 0) {
 502:                purple_debug_info("soap", "read %d bytes\n", cnt);
 [/snip]
 }}}
 Here the `conn->buf` seems to be botched for some reason (so we might
 check whether {{{conn->buf->len}}} really exists or better yet, find the
 cause why it is b0rked (a big fat assert for debugging :P).
 As most of the data in the backtrace seems to be optimized out, I cannot
 speculate further...


 And of course the something else I spotted:
 {{{
 489:         char buf[16 * 1024];
 ...
 497:                conn->buf = g_string_new_len(buf, 0);
 }}}

 Why not use GString and / or `g_string_sized_new`?

-- 
Ticket URL: <http://developer.pidgin.im/ticket/8594#comment:7>
Pidgin <http://pidgin.im>
Pidgin