diff options
author | Guy Harris <guy@alum.mit.edu> | 2015-05-10 14:16:14 -0700 |
---|---|---|
committer | Guy Harris <guy@alum.mit.edu> | 2015-05-10 21:18:53 +0000 |
commit | 42611db19ae539799de2a66fc53edecfdf9a27a9 (patch) | |
tree | d0ac095eb9a2adaf63f4343cd6d95b876d76b4d9 /test/run_and_catch_crashes | |
parent | 040641dc598b4d4873171a6700e202f5e8b8c318 (diff) |
Try wrapping some tshark invocations in a script to catch crashes.
Add a script that takes a command as an argument and runs it in a
subshell, so that said subshell will catch any signals from it and
report it.
This would be done for commands that aren't the last command in the
pipeline, as, given that the exit status of a pipeline is the exit
status of the last command in the pipeline, there's no guarantee that
the shell will bother to pick up the exit status of earlier commands in
the pipeline.
Use that for the tshark in the WPA EAPOL Rekey test, so it at least can
report the signal (on Solaris, SIGSEGV means, among other things,
"dereferenced a pointer pointing out of the address space" and SIGBUS
means, among other things, "dereferenced a misaligned pointer on
SPARC"). Maybe we can make the script also fire up a debugger if it
finds a core dump (and a debugger) and get a stack trace.
Change-Id: I4188190a1f1a4d3afc4719d886161ee56bd89d8b
Reviewed-on: https://code.wireshark.org/review/8392
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Diffstat (limited to 'test/run_and_catch_crashes')
-rwxr-xr-x | test/run_and_catch_crashes | 20 |
1 files changed, 20 insertions, 0 deletions
diff --git a/test/run_and_catch_crashes b/test/run_and_catch_crashes new file mode 100755 index 0000000000..7cc4c20cf2 --- /dev/null +++ b/test/run_and_catch_crashes @@ -0,0 +1,20 @@ +#! /bin/sh +# +# Run the command we're passed in a subshell, so that said subshell will +# catch any signals from it and report it. +# +# This is done for commands that aren't the last command in the +# pipeline, as, given that the exit status of a pipeline is the exit +# status of the last command in the pipeline, there's no guarantee that +# the shell will bother to pick up the exit status of earlier commands +# in the pipeline. +# +# XXX - it might be useful to try to catch core dumps and, if we find +# one, fire up some tool to try to get a stack trace. That's rather +# platform-dependent - not all platforms create a core dump file named +# "core" in the current directory (OS X, for example, defaults to +# "/cores/core.{PID}"), and the name of the debugger and commands to +# pass to it are platform-dependent (and you might not even have one +# installed). +# +"$@" |