It turned out to be one of the fields was redefined in the hf_register_info structure, thanks for the direction Jeff.
On 6/20/06, Jeff Morriss <jeff.morriss@xxxxxxxxxxx> wrote:
[FYI, Wireshark-dev is probably a better place to ask such questions now...]
Jim Fan wrote:
> Hi, I am getting an error in one of the packets I am decoding:
>
> dissector bug, protocol xxx: proto.c:2742 Failed assertion
> "(guint)hfIndex < gpa_hfInfo.len"
>
> I found that this could be related to the limitation of how many header
> fields can a protocol have. 200 is the default value. In my case I have
> over 200 header fields (approximately 260), therefore any header fields
> that is after the 200th are reported as assertion error. Ethereal should
> have the ability of dynamically increases the memory allocation on the
> go based on the dissector definition, but somehow I am getting this
> error here.
>
> Anyone has any idea about how to fix this problem?
The header fields are dynamically allocated--by the dissector, no less.
Are they all being registered in 'proto_register_field_array()'? Are
you sure you don't have something wrong with your 'hf_register_info'
array (maybe around the 200th entry) that causes
'proto_register_field_array()' to not read the whole array?
As an example, packet-h245.c has a few more than 200 header fields:
> mozart [~/Projects/wireshark/source/]> egrep -c "^static int hf" epan/dissectors/packet-
h245.c
> 1375
_______________________________________________
Ethereal-dev mailing list
Ethereal-dev@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/ethereal-dev