From: Mark D. <ma...@ki...> - 2006-04-27 21:53:34
|
On Wed, 8 Dec 2004 00:45:51 -0600, Evan Schoenberg wrote > I've noticed a rare crash which ICQ users run into... one could > point out it's their own fault for using ICQ, but that's not > relevant ;) > > Here's the stack trace: > 0 Libgaim 0x110386e4 aim_bstream_empty > + 0 1 Libgaim 0x110388fc aimbs_getle16 > + 0x18 2 Libgaim 0x11041774 > incomingim_ch2_icqserverrelay + 0x28 3 Libgaim > 0x11041d54 incomingim_ch2 + 0x494 4 Libgaim > 0x11041ff8 incomingim + 0xec 5 Libgaim > 0x1105404c consumesnac + 0xc8 6 Libgaim > 0x1105473c aim_rxdispatch + 0xc4 > > aim_bstream_empty(), for easy reference, is here: > faim_internal int aim_bstream_empty(aim_bstream_t *bs) > { > return bs->len - bs->offset; > } > > So clearly aim_bstream_empty() is being called with a NULL bs. This > stack trace is the -only- way I've seen a crash in > aim_bstream_empty... it's always coming an incoming channel2 > icqserverrelay call. > > I'd therefore think that incomingim_ch2_icqserverrelay() is where > some protection is needed (it'd be easy, of course, to simply make > aim_bstream_empty() return 0 if bs is NULL, but that seems wasteful > since it doesn't otherwise get called with a NULL bs). > Unfortunately, incomingim_ch2_icqserverrelay() has quite a few > aimbs_getle16() calls... so I'm not sure where the culprit lies. > Anyone have thoughts on it? Or, if not, would a safety check at a > lower level such as the aim_bstream_empty() call be reasonable? > > -Evan incomingim_ch2_icqserverrelay() currently returns without doing anything if the byte stream is NULL. It's very possible that check was added after you sent this email a year and a half ago. And I don't think it's possible for the byte stream to ever become NULL inside that function. So this crash shouldn't be possible any more. I'm going to move this email out of my inbox now... -Mark |