Michael Mann
changed
bug 12792
What |
Removed |
Added |
Status |
UNCONFIRMED
|
CONFIRMED
|
CC |
|
[email protected]
|
Ever confirmed |
|
1
|
Comment # 3
on bug 12792
from Michael Mann
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.