> peter@xxxxxxxxxxxx wrote:
>
> > To reproduce the error (access violation on Windows,
> segmentation fault on
> > Unix) do:
> > 1. Start a capture, any network data is feasible.
> > 2. Stop the capture (after a while, make sure you have at
> least one packet
> > to "decode as").
> > 3. Choose "Analyse -> Decode as" and choose any protocol
> other than the
> > one it actually is when captured.
> > 4. Let's say you choose ftp as the protocol to decode the
> captured stream
> > as. Now add ftp (only ftp) as filter, this shows of course only the
> > "Decode as" packets.
> > 5. Choose "Analyse -> Decode as -> default". This causes the access
> > violation in gtk\decode_as_dlg.c, routine static void
> > decode_transport(GtkWidget *notebook_pg). The first call to
> > "decode_change_one_dissector(table_name,
> cfile.edt->pi.srcport, list);"
> > fails since cfile.edt in this case is NULL.
>
> I tried that but couldn't reproduce the problem.
>
> "cfile.edt" should be non-null if a packet is selected, and
> if no packet
> is selected, the "Analyze -> Decode As" menu item should be disabled.
>
Hi,
This is my first post, I've just begun to try to understand Ethereal software, so please forgive me if I say or do something incorrect.
I've found this problem appears when you open the "Decode As" dialog and press Apply and then Accept, if applying the decoding change causes the packet you have selected to disappear from the packet list. So, in the case of the original e-mail:
- decode x as FTP
- set filter to FTP
- decode x as default
- "Apply" -> every packet is deleted from the packet list, including the selected one, since the display filter no longer applies to them; cfile.edt is set to NULL
- "Accept" -> decode_transport is invoked again, and it tries to use cfile.edt without first checking whether it exists
It is also possible to reproduce this simply by first setting the display filter to something that covers only a type of packets, selecting one of them, decoding it as anything else, applying and then accepting.
Since it is possible to do a number of changes in the decode before accepting, and applying or not after each of them, I think the only way out would be to store the information on the ports that were selected when the dialog opened. I've put this as a couple of information elements on the notebook page. I'm not familiar with GTK, but it seems to work as expected; however, I'm not really sure of whether the elements stored can be trusted -i.e. if it stores pointers to something that may be changed or the actual data-. I have looked at the documentation, but still I have doubts.
I cannot find a way to get the format you use for diffs for patches -diff -u doesn't work for me-, so I'm attaching a new version of decode_as_dlg.c and a comparison by an editor with the one in today's tarball.
Regards,
Francisco
Attachment:
decode_as_dlg.c
Description: Binary data
Attachment:
decode_as_dlg.diff
Description: Binary data