Build Information:
TShark 1.11.0 (SVN Rev 50449 from /trunk)
Copyright 1998-2013 Gerald Combs <[email protected]> and contributors.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Compiled (64-bit) with GLib 2.34.2, with libpcap, with libz 1.2.7, without
POSIX
capabilities, without libnl, without SMI, with c-ares 1.9.1, with Lua 5.1,
without Python, with GnuTLS 2.12.23, with Gcrypt 1.5.0, without Kerberos,
without GeoIP.
Running on Linux 3.9.2-200.fc18.x86_64, with locale C, with libpcap version
1.3.0, with libz 1.2.7.
Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz
Built using gcc 4.7.2 20121109 (Red Hat 4.7.2-8).
--
Got a fuzz failure (I have the optional "-Yframe -nr" test enabled in
fuzz-test.sh):
~~~
ERROR
Processing failed. Capture info follows:
Input file: ../caps/menagerie/public/10916-sling.pcap
Output file: /tmp/fuzz-2013-07-08-8759.pcap
stderr follows:
Input file: ../caps/menagerie/public/10916-sling.pcap
Build host information:
Linux mtl-morriss-d1.ulticom.com 3.9.2-200.fc18.x86_64 #1 SMP Mon May 13
13:59:47 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
Return value: 133
Dissector bug: 0
Valgrind error count: 0
Subversion revision
------------------------------------------------------------------------
r50449 | morriss | 2013-07-08 15:49:17 -0400 (Mon, 08 Jul 2013) | 6 lines
Include the output (fuzz'd) file name in the output when fuzz (or randpkt)
testing fails.
Useful for when you want to use up a few spare CPU cores running multiple
simultaneous fuzz tests...
------------------------------------------------------------------------
Command and args: ./tshark -Yframe -nr
** (process:8110): ERROR **: More than 1000000 items in the tree -- possible
infinite loop
~~~
Backtrace is, in part:
~~~
#0 0x0000003de1c4ec67 in g_logv () from /lib64/libglib-2.0.so.0
#1 0x0000003de1c4ee32 in g_log () from /lib64/libglib-2.0.so.0
#2 0x00007f8c0b0a3873 in proto_tree_add_text (tree=tree@entry=0x2da6380,
tvb=tvb@entry=0x2da6980, start=start@entry=56, length=length@entry=-1,
format=format@entry=0x7f8c0c4c42e9 "%s") at proto.c:994
#3 0x00007f8c0b2a90c5 in parseFields (tvb=tvb@entry=0x2da6980, tree=0x2da6380,
offset=56, offset@entry=12, parserNodes=parserNodes@entry=0x7f8c0d084c20
<DIS_PARSER_ACTION_REQUEST_PDU>)
at packet-dis-pdus.c:1305
#4 0x00007f8c0b2ab1cf in dissect_dis (data="" out>, tree=<optimized
out>, pinfo=0x7fff81429d80, tvb=0x2da6980) at packet-dis.c:409
#5 dissect_dis (tvb=0x2da6980, pinfo=0x7fff81429d80, tree=<optimized out>,
data="" out>) at packet-dis.c:166
#6 0x00007f8c0b0960bf in call_dissector_through_handle (handle=0x2bf59a0,
tvb=0x2da6980, pinfo=0x7fff81429d80, tree=0x2da6350, data="" at packet.c:454
#7 0x00007f8c0b0968ad in call_dissector_work (handle=0x2bf59a0,
tvb=tvb@entry=0x2da6980, pinfo_arg=pinfo_arg@entry=0x7fff81429d80,
tree=tree@entry=0x2da6350, add_proto_name=add_proto_name@entry=1,
data="" at packet.c:552
#8 0x00007f8c0b097100 in dissector_try_uint_new (sub_dissectors=<optimized
out>, uint_val=3000, tvb=tvb@entry=0x2da6980, pinfo=pinfo@entry=0x7fff81429d80,
tree=tree@entry=0x2da6350,
add_proto_name=add_proto_name@entry=1, data="" at packet.c:969
#9 0x00007f8c0b097157 in dissector_try_uint (sub_dissectors=<optimized out>,
uint_val=<optimized out>, tvb=tvb@entry=0x2da6980,
pinfo=pinfo@entry=0x7fff81429d80, tree=tree@entry=0x2da6350) at packet.c:995
#10 0x00007f8c0b72d7d5 in decode_udp_ports (tvb=tvb@entry=0x2d80f60,
offset=offset@entry=8, pinfo=pinfo@entry=0x7fff81429d80,
tree=tree@entry=0x2da6350, uh_sport=3000, uh_dport=3000, uh_ulen=64)
at packet-udp.c:280
~~~
I'll attach the capture file after fixing the bug.
