> > We used to *always* blow up. Now, we just blow up if we're filtering
> > packets and reconstructing the display, rather than initially
> > constructing the display - the fix I put in for the problem required
> > that there be only one packet in the list (so that we know which packet
> > we want), but, whilst that fixes the crash I discovered yesterday, the
> > current crash remains unfixed (it would've crashed before, just with a
> > different assertion).
>
> So, a selection happens before there are packets in the list.
The selection occurs right after a packet has been added to the
GtkCList; the packet is also already in the list of frames.
However, it occurs *before* "gtk_clist_append()" returns, which means it
occurs before we have a row number to stick into the "row" field of the
"frame_data" structure for the frame.
> If we were
> to not assert, but just silently ignore the fact that fd is NULL
> (i.e., return), will another selection happen once the packet list is
> unfrozen so that we can do something with it?
I think I tried that, and the answer is "no" - in the case I found,
where it blew up on an "update packet list as the capture occurs"
capture, the first packet was selected (i.e., it was blue), but it
wasn't expanded.
In any case, I've checked in a fix.
