Hi list,
I've picked up the unistim dissector a while ago and try getting it into
shape for checkin. Thing is that I'm currently running fuzztests which
for the most run fine, but now I've isolated a packet that causes a
segmentation fault. The problem is that I'm stuck looking for the cause.
When running Wireshark in DDD I find that the segfault occurs while
priming the display filter. This is the start of the backtrace:
#0 0xb6da2a46 in fvt_cache_cb (node=0x8a86a20, data=0x0) at
dfilter-macro.c:66
#1 0xb6d659d3 in proto_tree_traverse_in_order (tree=0x8a86a20,
func=0xb6da2a20 <fvt_cache_cb>, data=0x0) at proto.c:478
#2 0xb6d659bf in proto_tree_traverse_in_order (tree=0x8a86ac8,
func=0xb6da2a20 <fvt_cache_cb>, data=0x0) at proto.c:473
#3 0xb6d659bf in proto_tree_traverse_in_order (tree=0x8a37038,
func=0xb6da2a20 <fvt_cache_cb>, data=0x0) at proto.c:473
#4 0xb6d659bf in proto_tree_traverse_in_order (tree=0x8a37398,
func=0xb6da2a20 <fvt_cache_cb>, data=0x0) at proto.c:473
#5 0xb6d659bf in proto_tree_traverse_in_order (tree=0x8a373f8,
func=0xb6da2a20 <fvt_cache_cb>, data=0x0) at proto.c:473
#6 0xb6d659bf in proto_tree_traverse_in_order (tree=0x8a37980,
func=0xb6da2a20 <fvt_cache_cb>, data=0x0) at proto.c:473
#7 0xb6da2a0f in dfilter_macro_build_ftv_cache (tree_root=0x8a37980) at
dfilter-macro.c:87
#8 0x080707e0 in cf_select_packet (cf=0x81974c0, row=0) at file.c:3256
#9 0x0808db1a in packet_list_select_cb (w=0x8866010, row=0, col=-1,
evt=0x0) at packet_list.c:284
which leads to
--------------8<-------------
static gboolean fvt_cache_cb(proto_node * node, gpointer data _U_) {
field_info* finfo = node->finfo;
fvt_cache_entry_t* e;
if (!finfo) return FALSE;
if ((e = g_hash_table_lookup(fvt_cache,finfo->hfinfo->abbrev)))
--------------8<-------------
Where finfo->hfinfo proves to be 0x8. How does it get that value?
When running Tshark I get most of the output:
Frame 1 (124 bytes on wire, 124 bytes captured)
Ethernet II, Src: Cisco_1d:c9:c0 (00:13:80:1d:c9:c0), Dst:
Nortel_ff:c8:66 (00:13:65:ff:c8:66)
Internet Protocol, Src: 131.253.0.203 (131.253.0.203), Dst: 10.64.50.150
(10.64.50.150)
User Datagram Protocol, Src Port: commplex-main (5000), Dst Port: 22408
(22408)
UNISTIM Protocol
Reliable UDP
RUDP Seq Num: Normal Sequence Number (0x0000dbb4)
RUDP Pkt type: Payload (2)
UNISTIM Payload: Aggregate Unistim (0x01)
Unistim CMD
UNISTIM CMD Address: Display Manager Switch (0x17)
UNISTIM CMD Length: 5
Display Cmd (switch): Clear Field (0x0f)
0001 0000 = FLAGS: For Following Byte
.... ...0 = Numeric Index Field in InfoBar: False
.... ..0. = Context Field in InfoBar: False
.... .0.. = Date Field: False
.... 0... = Time Field: False
...1 .... = Line Data: True
..0. .... = Status Bar Icon: False
.0.. .... = Soft Key: False
0... .... = Soft Key Label: False
1111 1111 = FLAGS: For Following Byte
.... ...1 = Line 1: True
.... ..1. = Line 2: True
.... .1.. = Line 3: True
.... 1... = Line 4: True
...1 .... = Line 5: True
..1. .... = Line 6: True
.1.. .... = Line 7: True
1... .... = Line 8: True
Unistim CMD
UNISTIM CMD Address: Display Manager Switch (0x17)
UNISTIM CMD Length: 15
Display Cmd (switch): Display Data Write address|yes
control|no tag|no (0x19)
Address
0000 0100 = FLAGS: For Following Byte
.... ...0 = Is Address Numberic: False
.... ..0. = Context Field in the Info Bar: False
.... .1.. = Write A Line: True
.... 0... = Write a SoftKey: False
...0 .... = Write A Softkey Label: False
000. .... = Line Number: 0
DATA: 4. Feature
Unistim CMD
UNISTIM CMD Address: Display Manager Switch (0x17)
UNISTIM CMD Length: 16
Display Cmd (switch): Display Data Write address|yes
control|no tag|no (0x19)
Address
0000 0100 = FLAGS: For Following Byte
.... ...0 = Is Address Numberic: False
.... ..0. = Context Field in the Info Bar: False
.... .1.. = Write A Line: True
.... 0... = Write a SoftKey: False
...0 .... = Write A Softkey Label: False
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1237526864 (LWP 32058)]
proto_item_fill_label (fi=0x873e200, label_str=0xbfe6e4fc "...0 .... =
Write A Softkey Label: False") at proto.c:3865
3865 switch(hfinfo->type) {
Which, on closer examination shows that hfinfo is 0x8 as well. Why does
finfo->hfinfo gets set to 0x8?? That's the question.
Thanx,
Jaap
