Comment # 4
on bug 8728
from Jeff Morriss
(In reply to comment #3)
> (In reply to comment #2)
> > Oh, I also forgot to mention: it's not an infinite loop, just a very, very
> > long one. ;-)
> >
> > (I also forgot to make this bug public.)
> >
> > Since I forgot to make it public, reiterate this comment with the broader
> > audience:
> >
> > BTW I'm confused: I can't reproduce this bug with tshark, only with
> > Wireshark.
>
> More tree weirdness.
>
> In tshark running without -V runs with tree==null, so the loop is at least
> very fast (though it does run a ridiculous number of times, which is the
> bug) and there is no "too many items" warning because proto_tree_add_item is
> never called.
>
> In tshark running with -V runs with a fully functional tree, so the loop
> goes off the end of the TVB and throws an exception very quickly.
>
> In wireshark, however, we run with a 'hidden' tree, so tree is non-null
> (causing proto_tree_add_item to actually be called) however
> TRY_TO_FAKE_THIS_ITEM counts the calls (leading to the "too many items"
> warning) but still short-circuits before an exception can be thrown.
>
> Basically you are seeing the bug in tshark with no tree, it just doesn't
> display the warning and runs relatively fast because the loop is so tight in
> that case.
>
> I don't know if it's possible to make tshark run with a hidden tree or not...
In fact Jakub has the answer in
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3290#c16 : you need to use
a read filter.
Adding "-R tcp" to tshark's command line (without "-V" of course) makes tshark
hit this bug too. I'll check in (commented-out for now!) code to the fuzz
tools to do this (so we maybe we can remember :-)).
You are receiving this mail because:
- You are watching all bug changes.
