https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=12792
Michael Mann <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |CONFIRMED CC| |[email protected] Ever confirmed|0 |1 --- Comment #3 from Michael Mann <[email protected]> --- I can confirm this crashes on master with: tshark -2 -R "http" -r broken-reduced.pcap A better understanding of read filters may help me understand the issue, but I'll at least report what I saw/did. After duplicating the crash, I tried to narrow down the offending packet number. It appears to be "packet 48" (see later why I'm questioning the number). So I set a breakpoint for packet 48 in the HTTP dissector and stepped through in the debugger. I stepped all the way through and back out to the epan_dissect_run() call in process_packet_first_pass() (tshark.c). Within process_packet_first_pass() after epan_dissect_run() is called there's a check for a read filter: /* Run the read filter if we have one. */ if (cf->rfcode) passed = dfilter_apply_edt(cf->rfcode, edt); And it ends up with a passed = FALSE value (Based on looking at the capture in Wireshark, that seems to make sense because its frame 48 has no HTTP dissection) With that passed = FALSE value, that means the frame count isn't going to increment for the next packet. So tshark gets the "next packet" which it's telling dissectors is still "packet 48". Then the same thing happens again, where the read filter fails and passed = FALSE. This happens several times and eventually leads to the crash. What I don't understand is why we're not incrementing the frame count. Yes, we don't want certain frames displayed (because of the read filter), but we're passing the same pinfo->num value to multiple frames and that's probably confusing to dissectors that keep track of state information based on packet number. I think there have been cases made to always have consecutive frame numbers output when a read filter is applied, but I think capture/crash may be the counter argument for that. -- You are receiving this mail because: You are watching all bug changes.
___________________________________________________________________________ Sent via: Wireshark-bugs mailing list <[email protected]> Archives: https://www.wireshark.org/lists/wireshark-bugs Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs mailto:[email protected]?subject=unsubscribe
