https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=14472
Peter Wu <pe...@lekensteyn.nl> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |pe...@lekensteyn.nl
--- Comment #4 from Peter Wu <pe...@lekensteyn.nl> ---
Reproduced with v2.5.1rc0-544-g1ac90d5254 using Clang 5.0.1 and:
tshark -r 565c34461815a4dc3ec8d603ad273bb5.pcap -V
Possible relevant information about the capture:
Frame 1 has seqno 1, len = 1206, nextseq=1207
Frame 2 has seqno 4261299399 (0xfdfe44c7), len=0 (marked as out-of-order)
Frame 3 has seqno 1207 (len=1204)
For some weird reason, "src_list" contains only one data source (Frame) while
"fi->ds_tvb" was allocated via desegmented TCP data:
(gdb) down
#4 0x00007fffecc3a4eb in get_field_data (src_list=0x60200044b1f0 = {...},
fi=0x60800003bc20) at epan/print.c:1758
1758 g_assert_not_reached();
(gdb) p fi->ds_tvb
$5 = (tvbuff_t *) 0x6070000d3980
(gdb) p (void)__asan_describe_address (0x6070000d3980)
0x6070000d3980 is located 0 bytes inside of 72-byte region
[0x6070000d3980,0x6070000d39c8)
allocated by thread T0 here:
#0 0x5555556ef771 in malloc (run/tshark+0x19b771)
#1 0x7fffdebf35a9 in g_malloc /build/src/glib/glib/gmem.c:94
#2 0x7fffece37e73 in tvb_new_with_subset epan/tvbuff_subset.c:101:18
#3 0x7fffece3948c in tvb_new_proxy epan/tvbuff_subset.c:214:9
#4 0x7fffece188c5 in tvb_new_chain epan/tvbuff.c:131:18
#5 0x7fffeb242306 in desegment_tcp epan/dissectors/packet-tcp.c:3183:24
#6 0x7fffeb23ef8b in dissect_tcp_payload
epan/dissectors/packet-tcp.c:5684:9
#7 0x7fffeb2610fa in dissect_tcp epan/dissectors/packet-tcp.c:6522:13
...
(gdb) p src_list
$10 = 0x60200044b1f0 = {0x60200044b1b0}
(gdb) p *(struct data_source*)src_list[0]->data
$14 = {tvb = 0x6080000383a0, name = 0x60200044b1d0 "Frame"}
(gdb) p (void) __asan_describe_address (0x6080000383a0)
0x6080000383a0 is located 0 bytes inside of 88-byte region
[0x6080000383a0,0x6080000383f8)
allocated by thread T0 here:
#0 0x5555556ef771 in malloc (run/tshark+0x19b771)
#1 0x7fffdebf35a9 in g_malloc /build/src/glib/glib/gmem.c:94
#2 0x555555802b02 in frame_tvbuff_new frame_tvbuff.c:169:8
#3 0x55555575789d in process_packet_single_pass tshark.c:3523:32
#4 0x555555750bd7 in process_cap_file tshark.c:3348:11
#5 0x555555748586 in main tshark.c:2029:17
Since the TCP tvb is not added as data source, I would have expected it to use
the frame tvb instead but clearly that is not happening. The data source was
not visible because "remove_last_data_source" actually removed it.
Initial guess: to fix this issue, we must ensure that the tvb that was removed
by remove_last_data_source is not used anywhere.
--
You are receiving this mail because:
You are watching all bug changes.___________________________________________________________________________
Sent via: Wireshark-bugs mailing list <wireshark-bugs@wireshark.org>
Archives: https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe
