On Thu, Dec 27, 2001 at 10:09:37AM -0600, bgp4news@xxxxxxxxx wrote:
> I am writing a new dissector, it works fine when only one level
> tree was created. But, after adding two more levels of subtree, it
> always core dump, although it shows summary correctly, I knew
> something was wrong with setting constants or registering, however
> reading README.developer didn't help me solve this one. Is there a
> skeleton code for multi-level creation ?
>
> Here is the core.
> #0 0x88610030 in kill () from /usr/lib/libc.so.4
> #1 0x88648f7e in abort () from /usr/lib/libc.so.4
> #2 0x884eb17a in g_logv () from /usr/local/lib/libglib12.so.3
> #3 0x884eb231 in g_log () from /usr/local/lib/libglib12.so.3
> #4 0x81b1a00 in get_uint_value (tvb=0x83c5cb4, offset=40, length=
> 32,
> little_endian=0) at proto.c:472
> #5 0x81b1bba in proto_tree_add_item (tree=0x83c7450, hfindex=4582,
> tvb=0x83c5cb4, start=40, length=32, little_endian=0) at
> proto.c:566
The problem you're having has nothing to do with adding two levels of
subtree.
It has to do with the fact that Ethereal supports 1-byte, 2-byte,
3-byte, and 4-byte integer values, but doesn't support 32-byte integer
values...
...and the "length" argument to "proto_tree_add_item()" is the length of
the integer item *in bytes*.
"get_uint_value()" is aborting because it's detected that your code is
incorrect; it would have been incorrect even if you'd put it at the top
level of the tree.
If the item in question is truly a 32-byte item, you have to make it an
item of type FT_BYTES, for example, rather than FT_UINT8 or FT_UINT16 or
FT_UINT24 or FT_UINT32. (Yes, you could argue that it's confusing that
the number after FT_UINT8 is the size in bits rather than the size in
bytes, given that the length in "proto_tree_add_item()" is in bytes, but
so it goes....)
If it's a 32-*bit* item, pass an "length" argument of 4, rather than 32,
to "proto_tree_add_item()".