https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7332
--- Comment #2 from Bill Meier <wmeier@xxxxxxxxxxx> 2012-06-07 14:00:06 PDT ---
This patch caused 'tshark -G values' to crash.
Specifically, the presence of several hf[] entries wih BASE_EXT_STRING set but
without an associated 'strings' entry caused the
'proto_registrar_dump_values()' code in proto.c to crash.
I'm changing that proto.c code slightly to not crash in this case;
The missing 'strings' entry does not appear to cause any problems with other
code in proto.c.
(Extract of the diff for packet-h248-template.c
{ &hf_h248_pkg_name, {
"Package", "h248.package_name", FT_UINT16, BASE_HEX|BASE_EXT_STRING,
- &package_name_vals_ext, 0, NULL, HFILL }},
+ NULL, 0, NULL, HFILL }},
--
{ &hf_h248_event_name, {
"Package and Event name", "h248.event_name", FT_UINT32,
BASE_HEX|BASE_EXT_STRING,
- &event_name_vals_ext, 0, "Package", HFILL }},
+ NULL, 0, "Package", HFILL }},
"Package and Signal name", "h248.signal_name", FT_UINT32,
BASE_HEX|BASE_EXT_STRING,
- &signal_name_vals_ext, 0, "Package", HFILL }},
+ NULL, 0, "Package", HFILL }},
Specifically: the 'string' field was removed but BASE_EXT_STRING remains.
Even though 'proto_registrar_dump_values()' will be fixed to not crash, there
really shouldn't be any hf[] entries with BASE_EXT_StRING set but with no
associated 'string' entrry.
Can the BASE_EXT_STRING flag simply be removed from these entries (since the
'string' field is NULL), or is there something more complex going on since:
"All default package information included in new packages (built at runtime)."
When/how does the value string field of the hf[] entries get set ?
(P.S. Eventually the proto.c code will be changed to enforce a requirement that
BaSE_EXT_STRING and BASE_RANGE_STRING not be set w/o an associated 'strings'
entry).
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.