> You should be able to find a problem at field #315.
Yeh, you were right.
Problem was in my code around line 314-315.
When I was fixing registration table (as you sad : "..one thing that's
changed is tighter conformance checks on header fields..") I have
added new fixed line, but forgot to remove old one. So I got
duplicates like those two:
old line:
{ &hf_tp_validityPeriod, { "Validity Period", "tp.VALID", FT_NONE,
BASE_NONE, NULL, 0x00, "Validity Period", HFILL } },
new line:
{ &hf_tp_validityPeriod, { "Validity Period", "tp.VALID",
FT_ABSOLUTE_TIME, ABSOLUTE_TIME_UTC, NULL, 0x00, "Validity Period",
HFILL } },
I have removed first(old) line, and it works fine now ( calling
proto_register_field_array function only once)
> If you open up a console you should see something there as well.
No error was written to console during registration process. (console
is totally debug empty), that's reason, why I was thinking, that
problem is not in my code.
After registration, when I have started parsing of pcap (protocol),
errors occures (because of incomplete proto_register_field_array):
Warn Dissector bug, protocol MEDIO, in packet 1: proto.c:1571:failed
assertion "(guint)hfindex < gpa_hfinfo.len"
> BTW: Blurbs as "" are deprecated, just put in NULL.
Ok, thx, I have replaced it.
Thanks a lot for advice
Martin
On 8 November 2010 16:53, Jaap Keuter <jaap.keuter@xxxxxxxxx> wrote:
> Hi,
>
> There's no limit on this, but one thing that's changed is tighter
> conformance checks on header fields during registration.
> You should be able to find a problem at field #315. If you open up a
> console you should see something there as well.
> With your new loop you just reduce the impact. So, there's probably
> still a block of 'filters' that's not initialized, you just haven't
> found them yet.
>
> If you can post fields 310 up to 320 we might spot an issue.
>
> BTW: Blurbs as "" are deprecated, just put in NULL.
>
> Thanks,
> Jaap
>
