Wireshark-bugs: [Wireshark-bugs] [Bug 12792] tshark crashes at tvbuff.c:837 with read filter
Date Index · Thread Index · Other Months · All Mailing Lists
Date Prev · Date Next · Thread Prev · Thread Next
From: bugzilla-daemon@xxxxxxxxxxxxx
Date: Sat, 10 Dec 2016 02:07:53 +0000

changed bug 12792


What Removed Added
Status UNCONFIRMED CONFIRMED
CC   mmann78@netscape.net
Ever confirmed   1

Comment # 3 on bug 12792 from 
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.