Wireshark mailing list archives
Re: [Wireshark-commits] rev 43176: /trunk/epan/dissectors/ /trunk/epan/dissectors/: packet-ieee80211.c
From: Jeff Morriss <jeff.morriss.ws () gmail com>
Date: Wed, 20 Jun 2012 13:59:35 -0400
Finally got back to this...OK, so now I understand what was happening: the PDML generation code was trying to pull out the display value and, since it wasn't being found in the value_string (because it was an unexpected/fuzz'd value), it had to generate a numeric representation which it could not do because it had BASE_NONE.
So I added code to prevent registering such fields in r43412.BUT, in writing this email, I'm now realizing this isn't quite right: construct_match_selected_string() has a special case where it will generate the string representation of a value rather than the value itself, but only when display is BASE_NONE.
In other words, prior to the recent changes if I used BASE_NONE for a field (say, sctp.chunk_type) then if I did "prepare as filter" for that field, I'd get, for example:
sctp.chunk_type == "HEARTBEAT" whereas using BASE_DEC would give me: sctp.chunk_type == 4Now (in trunk and trunk-1.8) dissector writers no longer have that option. I'm not convinced they should; maybe we should always do one or the other (which?). Or we can give them the option and fix construct_match_selected_string() to handle the case when the strings function doesn't find a value (and thus drops through to the "get a numeric representation" code). Needs more thought. At the very least, the now-dead code at the beginning of construct_match_selected_string() should be cleaned up.
Maynard, Chris wrote:
Also, the bug reporter indicated: Unhandled exception ("proto.c:6698: failed assertion "DISSECTOR_ASSERT_NOT_REACHED"", group=1, code=4) ... so while it was a guess, it was an educated guess, and it really seemed to me that this was the cause. - Chris ________________________________________ From: wireshark-dev-bounces () wireshark org [wireshark-dev-bounces () wireshark org] On Behalf Of Maynard, Chris [Christopher.Maynard () GTECH COM] Sent: Saturday, June 09, 2012 2:40 PM To: Developer support list for Wireshark Subject: Re: [Wireshark-dev] [Wireshark-commits] rev 43176: /trunk/epan/dissectors/ /trunk/epan/dissectors/: packet-ieee80211.c It was a guess. The attachment in the bug report, namely "wint168.txt", only revealed the following:: This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. I didn't see anything wrong with the "wlan_mgt.fixed.capabilities.dsss_ofdm" field, which was the one in which the above message appeared, so I went looking for nearby fields for potential problems, and that's when I noticed that hf_ieee80211_tag_supp_rates had "FT_UINT8, BASE_NONE", and the display filter for that field is "wlan_mgt.supported_rates", which is the last thing printed in the wint168.txt file, so I figured that was most likely the problem. - Chris ________________________________________ From: wireshark-dev-bounces () wireshark org [wireshark-dev-bounces () wireshark org] On Behalf Of Jeff Morriss [jeff.morriss.ws () gmail com] Sent: Saturday, June 09, 2012 2:26 PM To: wireshark-dev () wireshark org Subject: Re: [Wireshark-dev] [Wireshark-commits] rev 43176: /trunk/epan/dissectors/ /trunk/epan/dissectors/: packet-ieee80211.c On 06/09/2012 01:08 PM, cmaynard () wireshark org wrote:http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=43176 User: cmaynard Date: 2012/06/09 10:08 AM Log: Do not use BASE_NONE for FT_UINT8 types. Fixes https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7333 (I think).The code in epan/proto.c seems to indicate that using BASE_NONE with FT_*INT* types should be OK when there the strings converter is supplied:case FT_UINT32: case FT_UINT64: if (hfinfo->strings == NULL) { /* Require integral types (other than frame number, * which is always displayed in decimal) to have a * number base */ if (hfinfo->display == BASE_NONE) g_error("Field '%s' (%s) is an integral value (%s)" " without strings but is being displayed as BASE_NONE\n", hfinfo->name, hfinfo->abbrev, val_to_str(hfinfo->type, hf_types, "(Unknown: %d)")); }Where was it crashing (er, excepting out)? (There's no sample PCAP file in that bug.)
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev () wireshark org> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-request () wireshark org?subject=unsubscribe
Current thread:
- Re: [Wireshark-commits] rev 43176: /trunk/epan/dissectors/ /trunk/epan/dissectors/: packet-ieee80211.c Jeff Morriss (Jun 09)
- Re: [Wireshark-commits] rev 43176: /trunk/epan/dissectors/ /trunk/epan/dissectors/: packet-ieee80211.c Bill Meier (Jun 09)
- Re: [Wireshark-commits] rev 43176: /trunk/epan/dissectors/ /trunk/epan/dissectors/: packet-ieee80211.c Maynard, Chris (Jun 09)
- Re: [Wireshark-commits] rev 43176: /trunk/epan/dissectors/ /trunk/epan/dissectors/: packet-ieee80211.c Maynard, Chris (Jun 09)
- Re: [Wireshark-commits] rev 43176: /trunk/epan/dissectors/ /trunk/epan/dissectors/: packet-ieee80211.c Jeff Morriss (Jun 20)
- Re: [Wireshark-commits] rev 43176: /trunk/epan/dissectors/ /trunk/epan/dissectors/: packet-ieee80211.c Jakub Zawadzki (Jun 20)
- Re: [Wireshark-commits] rev 43176: /trunk/epan/dissectors/ /trunk/epan/dissectors/: packet-ieee80211.c Maynard, Chris (Jun 09)
- Re: [Wireshark-commits] rev 43176: /trunk/epan/dissectors/ /trunk/epan/dissectors/: packet-ieee80211.c Alexis La Goutte (Jun 17)