On Thu, 31 Jan 2002 10:33:24 "Neulinger, Nathan" wrote:
> Not sure why, but this:
>
> if ( connect_tree && cd_len > 0)
> {
> proto_tree_add_item(connect_tree, hf_tns_connect_data, tvb,
> tns_offset+cd_offset,
> tvb_length_remaining(tvb, tns_offset+cd_offset), FALSE);
> }
>
> is generating:
>
> ** ERROR **: file proto.c: line 1626 (alloc_field_info): assertion failed: (hfinfo->type == FT_PROTOCOL || hfinfo->type == FT_NONE)
> aborting...
The assert in proto.c happens if length == -1. Note the comment:
if (length == -1) {
/*
* For FT_NONE or FT_PROTOCOL fields, this means "set the
* length to what remains in the tvbuff"; the assumption
* is that the length can only be determined by dissection,
* so we set it to that value so that, if we throw an
* exception while dissecting, it has what is probably the
* right value.
*
* It's not valid for any other type of field.
*/
g_assert(hfinfo->type == FT_PROTOCOL ||
hfinfo->type == FT_NONE);
length = tvb_length_remaining(tvb, start);
}
tvb_length_remaining() is returning -1. Here's the comment describing
tvb_length_remaining() in epan/tvbuff.h:
/* Computes bytes to end of buffer, from offset (which can be negative,
* to indicate bytes from end of buffer). Function returns -1 to
* indicate that offset is out of bounds. No exception is thrown. */
extern gint tvb_length_remaining(tvbuff_t*, gint offset);
If your string (hf_tns_connect_data) really is supposed to continue to
the end of the tvbuff, but the tvbuff has no more data, then an
exception needs to be thrown. The question becomes, should we
have a version of tvb_length_remaining() that can throw
an exception, or should the dissector check the return value of
tvb_length_remaining() and throw the exception. Probably the former.
Do you concur?
--gilbert