[ronnie sahlberg <ronniesahlberg@xxxxxxxxx>]

On 9/27/05, Olivier Biot (Ethereal) <ethereal@xxxxxxxxxxxxxxx> wrote:

Hi folks,

This bug is related to calling proto_item_append_string() which does a
progressive update of a FT_STRING or FT_STRINGZ field.

I have been looking at it for the past 6 hours, and have come to the
conclusion that a header field can get "promoted" to FT_PROTOCOL (FTENUM =
1), as can be seen from a private debug trace I generated with a patched
proto.c and packet-wsp.c (see below).

 

Is it possible that the TRY_TO_FAKE_THIS_ITEM speed optimization is causing
this?

Very likely.
You can disable this faking by changing a define at the top of the proto.c file   in case you want to verify   but i dont think that is nessecary.

Hmmm.
Maybe the better solution is to change proto_tree_append_string() to be "TRY_TO_FAKE_THIS_ITEM aware and thus IF the hf field we try to append to happens to be FT_PROTOCOL   then just silently return instead of causing an assert.

(FT_PROTOCOL fields are never faked)

 

If so, how can this be fixed? Do I have to manually set the visibility of
all these incrementally updateable fields to "always visible", or is there
another trick?