Comment # 1
on bug 12584
from Peter Wu
Can confirm that the crash happens (in frame 26).
Tested with tshark v2.3.0rc0-449-gf597234
ERROR:epan/print.c:1411:get_field_data: code should not be reached
(gdb) bt
#0 0x00007fffe0c8704f in raise () from /usr/lib/libc.so.6
#1 0x00007fffe0c8847a in abort () from /usr/lib/libc.so.6
#2 0x00007fffe1d79485 in g_assertion_message (domain=domain@entry=0x0,
file=file@entry=0x7fffef583e80 "epan/print.c", line=line@entry=1411,
func=func@entry=0x7fffef586ce0 <__func__.17627> "get_field_data",
message=message@entry=0x603000074fe0 "code should not be reached") at
gtestutils.c:2429
#3 0x00007fffe1d7951a in g_assertion_message_expr (domain=0x0,
file=0x7fffef583e80 "epan/print.c", line=1411,
func=0x7fffef586ce0 <__func__.17627> "get_field_data", expr=<optimized
out>) at gtestutils.c:2452
#4 0x00007fffec12eaea in get_field_data (src_list=0x615000110e00 = {...},
fi=0x7fffd5651e60) at epan/print.c:1411
#5 0x00007fffec12f954 in pdml_write_field_hex_value (pdata=0x7fffffffce40,
fi=0x7fffd5651e60) at epan/print.c:1539
#6 0x00007fffec125cd4 in proto_tree_write_node_pdml (node=0x7fffd5651ed0,
data="" at epan/print.c:621
#7 0x00007fffec1544c0 in proto_tree_children_foreach (tree=0x7fffd5651e20,
func=0x7fffec1232bb <proto_tree_write_node_pdml>,
data="" at epan/proto.c:690
#8 0x00007fffec126205 in proto_tree_write_node_pdml (node=0x7fffd5651e20,
data="" at epan/print.c:641
#9 0x00007fffec1544c0 in proto_tree_children_foreach (tree=0x619000155a70,
func=0x7fffec1232bb <proto_tree_write_node_pdml>,
data="" at epan/proto.c:690
#10 0x00007fffec1222ef in write_pdml_proto_tree (fields=0x60400004f150,
protocolfilter=0x0, edt=0x61400000ea40,
fh=0x7fffe0fed5e0 <_IO_2_1_stdout_>) at epan/print.c:308
#11 0x0000555555649d20 in print_packet (cf=0x555555808220 <cfile>,
edt=0x61400000ea40) at tshark.c:3855
#12 0x00005555556481fd in process_packet (cf=0x555555808220 <cfile>,
edt=0x61400000ea40, offset=3949, whdr=0x61300000d7a0,
pd=0x61d00019e680 "<\227\016J\321\032", tap_flags=0) at tshark.c:3447
#13 0x0000555555646da3 in load_cap_file (cf=0x555555808220 <cfile>,
save_file=0x0, out_file_type=2, out_file_name_res=0,
max_packet_count=-25, max_byte_count=0) at tshark.c:3189
#14 0x00005555556406f6 in main (argc=5, argv=0x7fffffffe258) at tshark.c:1889
(gdb) p *((struct data_source *)(src_list).data).tvb
$1 = {next = 0x61d000182b70, ops = 0x55555570b6a0 <tvb_frame_ops>, initialized
= 1, flags = 0, ds_tvb = 0x61d0001a6f60,
real_data = 0x61d00019e680 "<\227\016J\321\032", length = 1452,
reported_length = 1452, raw_offset = 0}
(gdb) p *fi->ds_tvb
$2 = {next = 0x61d000181cf0, ops = 0x7ffff05e12e0 <tvb_subset_ops>, initialized
= 1, flags = 0, ds_tvb = 0x61d000181c50,
real_data = 0x61c00000f880 "", length = 1792, reported_length = 1792,
raw_offset = -1}
Also interesting is that this capture triggers a dissection bug in the vnc
dissector after frame 1685.
epan/dissectors/packet-vnc.c:3249: failed assertion "bytes_needed != -1"
(gdb) up
#2 0x00007fffeb34b56b in vnc_tight_encoding (tvb=0x61d0001b7370,
pinfo=0x61400000ea58, offset=0x7fffffffad60, tree=0x7fffd564d070, width=6,
height=61440) at /tmp/wireshark/epan/dissectors/packet-vnc.c:3249
3249 DISSECTOR_ASSERT(bytes_needed != -1);
(gdb) info locals
per_packet_info = 0x7fffd5924e90
comp_ctl = 15 '\017'
compression_type_ti = 0x7fffd564d070
bit_offset = 32672
bytes_needed = -1
Feel free to take this bug to work on it.
