Limit Valgrind to the first 10,000 packets in each file.
Change-Id: I27be212ddb437c643ffb413bb9d1c809dbe98a55
Reviewed-on: https://code.wireshark.org/review/29210
Petri-Dish: Gerald Combs <gerald@wireshark.org>
Tested-by: Petri Dish Buildbot
Reviewed-by: Gerald Combs <gerald@wireshark.org>
Send it to same output file that gets the output ofthetest command, so
that it shows upin the output.
(I spent entirely too much time trying to figure out why 14738 was
happening on the buildbot but not on my machine - it turns out that the
test where it was failing was the one where -V *wasn't* specified, so
the protocol tree *wasn't* being generated, so proto_tree_add_string()
*wasn't* doing some tests that should have thrown an exception. The
output didn't make it clear that the test that was failing was the one
where the arguments to tshark were -nr, not -nVxr.)
Change-Id: I54e4450029ac56b9ac3d6eff9baf8acc849a5e4c
Reviewed-on: https://code.wireshark.org/review/28003
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Trap ABRT and try to pass it on to our runners.
Change-Id: I6e5a9fd63822c9bc84e116b3574abc4ccca448f5
Reviewed-on: https://code.wireshark.org/review/26227
Reviewed-by: Gerald Combs <gerald@wireshark.org>
Estimating the effort required to process a capture based on its size
isn't very reliable. Instead of rejecting files that are too large, just
limit Valgrind fuzzing to the first 100,000 packets in each file. This
should fix a timeout issue we're seeing on the master fuzzer.
Change-Id: I0117735341d3a183c6131f5f05dbd1d559fc4b3f
Reviewed-on: https://code.wireshark.org/review/23872
Reviewed-by: Gerald Combs <gerald@wireshark.org>
When we exit due to excessive memory leaks make sure we say so in the
error log.
Change-Id: I03f60271f3e4bb467fbaa5b9ac17431eed96f300
Reviewed-on: https://code.wireshark.org/review/23870
Reviewed-by: Gerald Combs <gerald@wireshark.org>
Make sure we check the exit status of the Valgrind process, not the most
recently executed command.
Change-Id: I3b6bd427383e4271b9ed38a10da6db506a511dc1
Reviewed-on: https://code.wireshark.org/review/18138
Reviewed-by: Gerald Combs <gerald@wireshark.org>
Look for shellcheck in Autotools and CMake, and if found add a target
that checks some of our shell scripts.
Add a "source=" directive to targets that include test-common.sh so
that shellcheck will correctly process the scripts. Note that this
requires shellcheck 0.4.0 or later.
To do: Fix the issues that shellcheck found and check more scripts.
Change-Id: I441f9f59d8a3f8eec6718119c2370f2560b98f3c
Reviewed-on: https://code.wireshark.org/review/17943
Petri-Dish: Gerald Combs <gerald@wireshark.org>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Gerald Combs <gerald@wireshark.org>
Try to determine if we passed -fsanitize=address to gcc or clang and
adjust the ASAN variable fuzz-test.sh, randpkt-test.sh and
test-captures.sh accordingly.
Change-Id: I88a34828fb5875e1a74a3b180ffb3da37daac0bd
Reviewed-on: https://code.wireshark.org/review/17848
Reviewed-by: Pascal Quantin <pascal.quantin@gmail.com>
Other limits are set with -S, do that with the virtual address space
limit as well.
Change-Id: Ie427341a4c7be56d3e8d96be6c1713c56e9bad87
Reviewed-on: https://code.wireshark.org/review/17846
Reviewed-by: Guy Harris <guy@alum.mit.edu>
When we set VG_ERR_CNT=1 print the reason.
Change-Id: Icb8f2a1e7074044521873b116fc891cc4be4b204
Reviewed-on: https://code.wireshark.org/review/17287
Reviewed-by: Gerald Combs <gerald@wireshark.org>
That way if we pass a file that doesn't exist to the fuzz-test script we won't
get errors from 'ls' complaining that the file doesn't exist.
Change-Id: I33f4bd692775e6d3f990adaaa37b7530d343fe52
Reviewed-on: https://code.wireshark.org/review/15410
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Run each "argument" test (e.g. "-nVxr" and "-nr") simultaneously in
the background. This should speed up our tests without reducing the
amount of fuzzing that we do.
Change-Id: I737d1dc09b31e07910d56632bec62da0f35fe222
Reviewed-on: https://code.wireshark.org/review/14432
Reviewed-by: Jaap Keuter <jaap.keuter@xs4all.nl>
Reviewed-by: Gerald Combs <gerald@wireshark.org>
This option skips some bytes when fuzzing, that prevents some headers from being changed. This focuses fuzzer to a smaller part of the packet.
Change-Id: I1db83235e93f2774a9991e3af70f633487b816fa
Reviewed-on: https://code.wireshark.org/review/9982
Petri-Dish: Anders Broman <a.broman58@gmail.com>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Follow-up to g2eabd35 which added a 20MB limit, this lowers it quite a bit since
we're still seeing out-of-memory failures with files slightly larger than 8MB.
Based on a quick scan of the menagerie this only excludes another dozen or so
files so we won't lose much coverage.
Ping-Bug: 11395
Change-Id: I8d684bebad553408c68b125330f2878deedc3bff
Reviewed-on: https://code.wireshark.org/review/9849
Reviewed-by: Evan Huus <eapache@gmail.com>
They run the buildbot out of memory, so just skip them, we don't want to remove
them from the menagerie entirely.
("large" here is > 20000 KB, but that could change)
Change-Id: I58dd9a981be6e6fc661ea624cc0c5258a5986a9f
Ping-Bug: 11395
Reviewed-on: https://code.wireshark.org/review/9768
Reviewed-by: Evan Huus <eapache@gmail.com>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
For out-of-tree builds you have to pass the location of your build to our tools
like the fuzz script, valgrind script etc. Modify them so that the value can be
set in the environment rather than requiring a shell script flag.
Set the environment variable in the vagrant provision step, so that the scripts
Just Work (TM) in the VM.
Change-Id: If8ce6b278176085ba6dd994137b82fc989b80124
Reviewed-on: https://code.wireshark.org/review/9168
Reviewed-by: Evan Huus <eapache@gmail.com>
Some captures are still hitting the limit as a false positive.
Bug: 10122
Change-Id: I12dd26ba0f96f44799f5ae642b1f9b0487f86a8a
Reviewed-on: https://code.wireshark.org/review/3982
Reviewed-by: Michael Mann <mmann78@netscape.net>
Down from 500KB. The old value only triggered once that I can recall, and the
"average" leakage I'm seeing on most captures is only a few KB now, so this
shouldn't flood us with issues (which was the original concern leaving it so
high).
Change-Id: Ie4c98696b3fb7a533a7dc4f83c7ac8c458b499c8
Reviewed-on: https://code.wireshark.org/review/2633
Reviewed-by: Michael Mann <mmann78@netscape.net>
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
Gerald Combs