The capture on bug 10098 times out but I don't see any culprits for bad loops or
anything - I think the capture is just too big. I'd prefer somebody else take a
look at it to verify I'm not missing anything before submitting this.
Bug:10098
Change-Id: I2cc43fd6ac9afaa345e7d31184483a9732fd6bf0
Reviewed-on: https://code.wireshark.org/review/1583
Reviewed-by: Gerald Combs <gerald@wireshark.org>
Reviewed-by: Evan Huus <eapache@gmail.com>
- Add -b option to randpkt-test.sh and test-captures.sh;
- Create/ue a common function to do '-x' tests on files/dirs;
- Rename exit_error function to ws_exit_error
Change-Id: I032c9d784bec1fb6b0717aaad08a061e4d935476
Reviewed-on: https://code.wireshark.org/review/872
Reviewed-by: Bill Meier <wmeier@newsguy.com>
Tested-by: Bill Meier <wmeier@newsguy.com>
There are a few things in here which could still use attention.
Don't regenerate anything now.
Change-Id: I283c224d3523212144707fca3d6265916cb11792
Reviewed-on: https://code.wireshark.org/review/205
Reviewed-by: Jeff Morriss <jeff.morriss.ws@gmail.com>
environments that are not the build tree (namely the fuzz-bot, but this might
make normal out-of-tree builds easier too).
svn path=/trunk/; revision=51387
- fix a few pieces of bad indentation
- exit cleanly in all cases where we receive a SIGINT or other signal
- check for valgrind bugs and dissector errors with every set of arguments (-nr
vs -nVxr etc) not just the last
- consider it an error if valgrind reports more than 500KB of leaked memory
For the last point, 500KB is hopefully a safe choice for now since we only leak
about 2KB "by default" and I have no idea what the state of most "non-default"
code is with respect to memory leaks. I would like to eventually work this
down to 0 of course :)
svn path=/trunk/; revision=50895
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
Evan Huus