Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-bugs: [Wireshark-bugs] [Bug 7210] Buildbot crash output: fuzz-2012-04-27-376.pcap

Date: Fri, 27 Apr 2012 19:54:52 -0700 (PDT)
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7210

--- Comment #5 from Evan Huus <eapache@xxxxxxxxx> 2012-04-27 19:54:52 PDT ---
(In reply to comment #4)
> (In reply to comment #3)
> > "Exception Occurred" means the dissector did crash
> 
> No, it means that the dissector called a tvbuff routine to fetch some data and
> the data wasn't actually present in the tvbuff; this either means
> 
>     1) the dissector is attempting to fetch data that is legitimately not
> there, which is a dissector bug;

Yes.

>     2) the dissector is attempting to fetch data that is supposed to be there,
> but that isn't there in the packet, which is *not* a dissector bug, it's a
> malformed packet;

Most of the time (in my experience) this is due to the dissector not validating
a length field, in which case it is more correct for the dissector to validate
the field against tvb_reported_length() or tvb_reported_length_remaining(), add
an expert info to the actual malformed field, and continue on to dissect as
much of the rest of the packet as it can.

>     3) the dissector is attempting to fetch data that is supposed to be there,
> but isn't there because reassembly wasn't done, which is *not* a dissector bug,
> it's a preference setting that prevents reassembly or something such as that;

Fair enough.

>     4) the dissector is attempting to fetch data that is supposed to be there,
> and that was there in the packet, but got discarded by the snapshot length
> being set, which is *not* a dissector bug, it's a case of "if you cared about
> this you should have used a bigger snapshot length".

In this case, the message is not "Malformed Packet (Exception occurred)" but
"Packet size limited during capture", which isn't caught by the filter I
applied.

> In most cases, it's 2, 3, or 4, which are, as noted, not dissector bugs, so
> there's nothing to fix.

Fair enough. Is there a way to differentiate the error messages for 2 and 3
(the way that 4 already is) so that it's easy to tell if it's a genuine bug or
not?

-- 
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.