On Mon, Jan 03, 2000 at 04:29:35PM -0600, Guy Harris wrote:
>
>
> The underlying problem is that, when you've selected "Scroll" mode for
> the packet list display (which is what GTK+ (and Motif) call "browse"
> mode - yes, the names we use are the reverse of what GTK+ and Motif
> use), the display list insists on there being a selected packet, so,
To me the opposite names make sense, but if you think it will cause
confusion, we can change naming schemes.
> when the first packet is added to the list, it selects it.
>
> Unfortunately, that happens before the routine to add a packet to the
> list returns, so it happens before the row number is set in the data
> structure for that packet; thus, we can't find the packet corresponding
> to that row, and we blow up.
>
> 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. 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? Or did the timing of
the initial selection move?
--gilbert
