ICQ Crash... stack trace and thoughts

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:
<x-tad-smaller>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

</x-tad-smaller>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