Another (related) question:
proto_tree_add_item() generates a core (from 'assert()') if the item I'm
adding is, say, a UINT32 but I pass in a length > 4.
I wanted to rewrite "packet-sccp.c" to NOT do:
reference = tvb_get_ntoh24(tvb, 0);
proto_tree_add_uint(tree, hf_sccp_dlr, tvb, 0, length, reference);
but instead do:
proto_tree_add_item(tree, hf_sccp_dlr, tvb, 0, length, FALSE);
But the problem is that I'm using (what is supposed to be) the length of
the parameter from the SCCP message, but it can be very wrong if, for
example, "mtp3.standard" is set incorrectly for the current capture.
The problem I have is that with the existing code I get "malformed
packets" and with the new code I get cores (which aren't conducive to
allowing me to change the "mtp3.standard" setting).
Is it possible that 'proto_tree_add_item()' could generate an exception
(instead of a core) in this (and similar) cases?
Devin Heitmueller wrote:
While on this topic, is there an easy way to cause Ethereal to break on
an event like this (or pull an assert)? With complex packet structures,
it is often difficult to determine which line of code performed the
invalid read.
-Devin
On Fri, 2003-03-21 at 13:55, Guy Harris wrote:
On Fri, Mar 21, 2003 at 11:23:11AM +0100, ana wrote:
I'm using ethereal on linux. I'm working on a DSR (Dynamic Source Route)
dissector, everything works, but at the end of the packet ethereal
reports Malformed packet.
I have no idea that could mean.
It means that some dissector is attempting to fetch stuff from the
packet that's past the end of the packet - i.e., the dissector thinks
there's something that should be in the packet, presumably because the
protocol specification says it should be in the packet, but, in fact,
it's not in the packet. A packet that's missing something that's
supposed to be in the packet would be malformed.