On Sun, Dec 09, 2001 at 11:49:15AM -0000, Gordon McKinney wrote:
> I have seen that too. Since I haven't ever done any GLib programming I will
> have to leave that one open to the group.
>
> The problem however has always been present during the time I've been using
> TCP Graph code, 0.8.19 and 0.8.20. Therefore I have baselined that bug when
> indicating that the PPP and Ethernet framing code works.
I've never seen this behavior but I'm basically using Ethereal on Linux
exclusively. If the broken redraw behavior is frequent and repeatable,
I'd be inclined to say that the problem is not in expose handling of
graph windows.
> There is another bug that I haven't had time to look at. If you follow a TCP
> stream, or set up a filter, then selecting the graph crashes on Win32. I
> haven't had time to see if it's simply my build on Win32 or whether it is a
> generic problem. In any case the benefits of the graph code outway any bugs
> it has.
I looked into it last weekend (even though I didn't let you know :( )
and I found that this is a generic problem caused by my misuse of
Ethereal's internal API. Function update_packet_list() uses a code that
IIRC I copied from somewhere without really understanding how it works,
to make the clicked segment current (selected) in the packet list. This
use of the code is buggy because it stops working once a filter has been
applied to the packet list. I'm not really sure how exactly the bug is
triggered but my hypothesis is that basically, I use frame_data::num
(frame number) information as the second argument of select_packet()
call. If I get it right select_packet() expect clist *row* number as its
second argument. So all is fine and well until you apply a filter at
which moment frame numbers a row numbers stop being identical any more.
gtk_clist_get_row_data() call in select_packet() then returns NULL and
consequently wtap_seek_read() crashes while dereferencing a NULL
pointer.
Even if this is the right explanation of the crash, unfortunatelly, I
failed to figure how a fix. I intended to send a query to the list but
not before I investigate properly myself. I tried to make sure that the
frame in question passed the dfilter before I called select_packet() on
it, I tried to use gtk_clist_find_row_from_data() to convert from
frame_data to row number but with every "solution" I tried so far
behavior of the frame selection code became erratic and finally it
crashed.
OK - could anybody please tell me how I should select a packet in
packet list if I know its frame number (frame_data::num)?
> If I get time then a may look into it. Is Pavel still around? I haven't
> heard anything from him in several weeks now. He would be ideal to fix the
> problem if he gets time.
I apologize for not being able to get back to you sooner. I've been chin
deep in personal sh*t recently (illness, work, etc.) but I hope things
are gradually getting better now so I should be able to work on Ethereal
again.
pvl