Add a new environment variable to cause abort()s if we add too many items

to the tree (to separate this case from the generic DISSECTOR_BUG case).

Enable this environment variable when fuzz testing.

Enable the 3rd (without tree but with a read filter) check (added in r49643)
when testing capture files but not when fuzz testing--not sure if we want to
add even more to the fuzzbot's work load now (OTOH I've been running it for
a while and it hasn't buried me in bugs).

svn path=/trunk/; revision=49784

doc/rawshark.pod

@@ -484,6 +484,18 @@ your environment is configured correctly, generate a core dump file.
 This can be useful to developers attempting to troubleshoot a problem
 with a protocol dissector.
 
+=item WIRESHARK_ABORT_ON_TOO_MANY_ITEMS
+
+If this environment variable is set, B<Rawshark> will call abort(3)
+if a dissector tries to add too many items to a tree (generally this
+is an indication of the dissector not breaking out of a loop soon enough).
+abort(3) will cause the program to exit abnormally; if you are running
+B<Rawshark> in a debugger, it should halt in the debugger and allow
+inspection of the process, and, if you are not running it in a debugger,
+it will, on some OSes, assuming your environment is configured correctly,
+generate a core dump file.  This can be useful to developers attempting to
+troubleshoot a problem with a protocol dissector.
+
 =item WIRESHARK_EP_VERIFY_POINTERS
 
 This environment variable, if set, causes certain uses of pointers to be

doc/tshark.pod

@@ -1642,6 +1642,18 @@ your environment is configured correctly, generate a core dump file.
 This can be useful to developers attempting to troubleshoot a problem
 with a protocol dissector.
 
+=item WIRESHARK_ABORT_ON_TOO_MANY_ITEMS
+
+If this environment variable is set, B<TShark> will call abort(3)
+if a dissector tries to add too many items to a tree (generally this
+is an indication of the dissector not breaking out of a loop soon enough).
+abort(3) will cause the program to exit abnormally; if you are running
+B<TShark> in a debugger, it should halt in the debugger and allow
+inspection of the process, and, if you are not running it in a debugger,
+it will, on some OSes, assuming your environment is configured correctly,
+generate a core dump file.  This can be useful to developers attempting to
+troubleshoot a problem with a protocol dissector.
+
 =item WIRESHARK_EP_VERIFY_POINTERS
 
 This environment variable, if present, causes certain uses of pointers to be

doc/wireshark.pod.template

@@ -2790,6 +2790,18 @@ your environment is configured correctly, generate a core dump file.
 This can be useful to developers attempting to troubleshoot a problem
 with a protocol dissector.
 
+=item WIRESHARK_ABORT_ON_TOO_MANY_ITEMS
+
+If this environment variable is set, B<Wireshark> will call abort(3)
+if a dissector tries to add too many items to a tree (generally this
+is an indication of the dissector not breaking out of a loop soon enough).
+abort(3) will cause the program to exit abnormally; if you are running
+B<Wireshark> in a debugger, it should halt in the debugger and allow
+inspection of the process, and, if you are not running it in a debugger,
+it will, on some OSes, assuming your environment is configured correctly,
+generate a core dump file.  This can be useful to developers attempting to
+troubleshoot a problem with a protocol dissector.
+
 =item WIRESHARK_EP_VERIFY_POINTERS
 
 This environment variable, if set, causes certain uses of pointers to be

tools/fuzz-test.sh

@@ -60,13 +60,10 @@ else
     # r Read packet data from the following infile
     RUNNER="$TSHARK"
     declare -a RUNNER_ARGS=("${CONFIG_PROFILE}${TWO_PASS}-nVxr" "${CONFIG_PROFILE}${TWO_PASS}-nr")
-    # Running with a read filter but without generating the tree exposes some "More than 100000 items
-    # in tree" bugs (which currently need WIRESHARK_ABORT_ON_DISSECTOR_BUG to be noticed--maybe that
-    # error should have its own environment variable?).
-    # Leave this commented out for now until someone has time to run it through the menagerie once
-    # or twice (so we don't get buried in bugs)...
+    # Running with a read filter but without generating the tree exposes some
+    # "More than 100000 items in tree" bugs.
+    # Not sure if we want to add even more cycles to the fuzz bot's work load...
     #declare -a RUNNER_ARGS=("${CONFIG_PROFILE}${TWO_PASS}-nVxr" "${CONFIG_PROFILE}${TWO_PASS}-nr" "-Yframe ${CONFIG_PROFILE}${TWO_PASS}-nr")
-    #export WIRESHARK_ABORT_ON_DISSECTOR_BUG=
 fi
 
 

tools/test-captures.sh

@@ -55,17 +55,14 @@ do
 		if $BIN_DIR/tshark -nr $file > /dev/null
 		then
 			echo "OK"
-			# We may not be ready to looking for all these bugs yet...
-			#echo -n " - without tree but with a read filter... "
-			#export WIRESHARK_ABORT_ON_DISSECTOR_BUG=
-			#if $BIN_DIR/tshark -Yframe -nr $file > /dev/null
-			#then
-			#	echo "OK"
-			#else
-			#	echo "Failed"
-			#	exit 1
-			#fi
-			#unset WIRESHARK_ABORT_ON_DISSECTOR_BUG
+			echo -n " - without tree but with a read filter... "
+			if $BIN_DIR/tshark -Yframe -nr $file > /dev/null
+			then
+				echo "OK"
+			else
+				echo "Failed"
+				exit 1
+			fi
 		else
 			echo "Failed"
 			exit 1

tools/test-common.sh

@@ -67,6 +67,8 @@ export WIRESHARK_EP_VERIFY_POINTERS=
 export WIRESHARK_SE_VERIFY_POINTERS=
 # Use the Wmem strict allocator which does canaries and scrubbing etc.
 export WIRESHARK_DEBUG_WMEM_OVERRIDE=strict
+# Abort if a dissector adds too many items to the tree
+export WIRESHARK_ABORT_ON_TOO_MANY_ITEMS=
 
 # Turn on GLib memory debugging (since 2.13)
 export G_SLICE=debug-blocks