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
Running tshark with a read filter ("-R") and without building the full tree
("-V") causes it to run into some more bugs (usually loops adding more than
100000 items to the tree). Add some (commented out for now) code to do
this...
svn path=/trunk/; revision=49643
the build-bot's valgrind pass wasn't running with/without tree. It's still
broken, but the debug output wasn't giving us any useful information.
svn path=/trunk/; revision=49464
------------------------------------------------------------------------
r47305 | gerald | 2013-01-26 12:12:52 -0800 (Sat, 26 Jan 2013) | 6 lines
Changed paths:
M /trunk-1.8/tools/fuzz-test.sh
Instead of setting resource limits on the fuzz-test.sh process itself,
set limits on the TShark subprocess. This should hopefully take care
of the strange fuzz failures we've seen lately.
Reduce the maximum CPU time to 5 minutes while we're at it.
------------------------------------------------------------------------
svn path=/trunk/; revision=47307
doesn't seem (to me) to warrant preventing someone from fuzz-testing.
Anyone know why this was put in in the first place?
svn path=/trunk/; revision=45733
These happen when, eg, a program runs out of memory under valgrind
or other more fatal errors (that may sometimes be valgrind bugs instead).
svn path=/trunk/; revision=44451
- add support for 2-pass dissection and config profiles
- make whitespace a consistent 4-spaces
fuzz-test.sh:
- update 2-pass support to use -2 and not the old -P
- add support for fuzz-testing under valgrind with the new -g option
svn path=/trunk/; revision=44024
Move the setting of debug environment variables out of the while loop.
Export MALLOC_OPTIONS=AJ to increase memory allocation debug on FreeBSD (and
others).
Export a number of environment variables that MacOS looks at.
(I don't have easy access to either of these OS so this has not been tested.)
Add a comments for each entry explaining which OS uses it and what it does.
svn path=/trunk/; revision=36622
From the GLib docs
"Using this option (present since GLib-2.13) engages extra code which
performs sanity checks on the released memory slices. Invalid slice
addresses or slice sizes will be reported and lead to a program halt."
svn path=/trunk/; revision=35165
WIRESHARK_SE_VERIFY_POINTERS that control whether or not we verify if a given
pointer is ep_ or se_ allocated, respectively.
Turn the behavior off by default for speed reasons (the speed difference isn't
huge, but...).
Turn the behavior on when fuzz testing.
Document these two new variables in the man pages.
svn path=/trunk/; revision=34046
this value will cause glibc to do some memory allocation checking for us and
abort if it finds a problem.
(If we're not on a glibc-based system this will have no effect but should also
do no harm.)
(I think the buildbot already runs with this set but it's better for all of us
to have it set, too.)
svn path=/trunk/; revision=32528
so far will take a while and in the meantime looking for dissector
assertions is keeping us from finding more serious bugs.
svn path=/trunk/; revision=29395
1. If enabled: the variable must be exported to the env to take effect;
2. Upon reflection: disable this feature:
tshark has been changed to output WARNING messages to stderr as a
default; This means that DISSECTOR_BUGs and failed DISSECTOR_ASSERTs
which cause WARNING log level messages will thus be output to stderr and
thus will be detected by the fuzz-test.
svn path=/trunk/; revision=29330
I noticed that when you run fuzz testing from both a root account and
a user account you can run into problems because the user account tries
to use and delete temp files created by the root account and fails. This
patch uses the same scheme as used for fuzz error files for naming the
tampered file and for the error file to prevent filename/permission
collisions between temp files from different runs.
svn path=/trunk/; revision=17145
Limit the amount of VM the process can use (default 500 MB). If we
can't save a capture in libpcap format, try again with the encapsulation
type set to "ether".
svn path=/trunk/; revision=14156
"./tools/fuzz-test.sh /path/to/capture/files/*" will iterate over the
specified capture files, using editcap to introduce errors and tethereal
to check for bugs. It will do this until tethereal exits abnormally or
a dissector bug is encountered.
svn path=/trunk/; revision=14073
Jeff Morriss