This is a static archive of our old Q&A Site. Please post any new questions and answers at

dissector bug: proto.c:656: failed assertion “(guint)hfindex < gpa_hfinfo.len”


I search on Google about this failure. Mostly of them suggested to check whether there were variables that were used without going into the hf array.

But I checked carefully both with and manually, no variable were used in such way.

Another thing is that my dissector was originally built as a plugin DLL with 0.99.5 wireshark. Now we are using wireshark 1.2.x(for the one I use now is 1.2.11), but in 1.2.x, there was a built-in wireshark dissector for my protocol(FMP) package. The way I tried to solve this problem was I copied the entire plugin source code and modified to build with 1.2.x. The dissector(dll) work with 1.2.x because I changed the protocol register name. I saw my dll recognized most of the packet except two packets, which displyed the error: dissector bug: proto.c:656: failed assertion "(guint)hfindex < gpa_hfinfo.len".

Any body has any suggestion to what happened or where the problem might be? I can't paste code at this moment because of a lot of reason.

Thanks in advance for your input.

asked 01 Nov '10, 23:27

alvan's gravatar image

accept rate: 0%

2 Answers:


Load the offending capture, try to work out which of the fields cause the error, then go back to your code to verify that that field has indeed been allocated. Use your debugger to make sure.

answered 02 Nov '10, 00:00

Jaap's gravatar image

Jaap ♦
accept rate: 14%

The line with a "*" is the field that cause the error. However, I checked carefully in my code, they are indeed allocated:

  • offset = dissect_rpc_uint64(tvb, tree, hf_fmp2_blockIndex, offset);

This is the line declaring the variable:

static int hf_fmp2_blockIndex = -1;

This is entry in hf array:

{ &hf_fmp2_blockIndex, { "Block Index", "fmp2.offset", FT_UINT64, BASE_DEC, NULL, 0, "Block Index", HFILL }},

Anything wrong? I really didn't see anything wrong. Sorry, I mean to paste more code, but it's too hard to paste code in the reply text box because it doesn't display code in well format.

(02 Nov '10, 00:20) alvan

Thanks for your quick response. See my addition below.

(02 Nov '10, 00:21) alvan

By the way, the code(built as dll) worked fine with 0.99.5 wireshark. When porting to 1.2.x, I didn't change anything except some Makefile to adapt to new building process. The whole building process with 1.2.x didn't show any errors.

(02 Nov '10, 00:30) alvan



I think you know this is a classical error when some hf proto fields are missing in the hf array since you ran the script.

I got exactly the same error on my custom dissector when upgrading from version 1.2.x to 1.4.x and it took me days to find out out what was wrong...

Indeed the error happened in my dissector during UDP reassembling, more precisely when I was running the process_reassembled_data function.

The cause was that in the fragment_items structure, the hf_xxx_reassembled_length field was missing. It was working fine until version 1.2.x but did not work after version 1.4.x

I think script did not catch it because the reassembling hf variables are initialised in another sources files (proto.c).

Tell me if it helps !



answered 16 Nov '10, 08:59

manux's gravatar image

accept rate: 0%

edited 16 Nov '10, 10:33

Indeed, the root cause was revision 31767 of reassemble.h (2 Feb 2010) : Introduce "Reassembled length" filter element for all protocols doing reassembly.

typedef struct _fragment_items {
    gint    *ett_fragment;
    gint    *ett_fragments;
int *hf_fragments;
int *hf_fragment;
int *hf_fragment_overlap;
int *hf_fragment_overlap_conflict;
int *hf_fragment_multiple_tails;
int *hf_fragment_too_long_fragment;
int *hf_fragment_error;
int *hf_reassembled_in;
int *hf_reassembled_length;

const char  *tag;

} fragment_items;

(17 Nov ‘10, 01:57) manux