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>
2015-05-10 21:16:14 +00:00
|
|
|
#! /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.
|
|
|
|
#
|
2015-05-11 17:18:30 +00:00
|
|
|
# XXX - on OS X, core dumps are in /cores/core.{PID}; would they appear
|
|
|
|
# elsewhere on any other UN*X?
|
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>
2015-05-10 21:16:14 +00:00
|
|
|
#
|
2015-05-11 17:18:30 +00:00
|
|
|
rm -f core
|
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>
2015-05-10 21:16:14 +00:00
|
|
|
"$@"
|
2015-05-11 17:18:30 +00:00
|
|
|
if [ -r core ]
|
|
|
|
then
|
|
|
|
#
|
|
|
|
# Core dumped - try to get a stack trace.
|
|
|
|
#
|
2015-05-11 19:22:23 +00:00
|
|
|
# First, find the executable. Skip past env and any env
|
|
|
|
# arguments to find the actual executable path. (If you
|
|
|
|
# run a program with an explicit path, and it dumps core,
|
|
|
|
# at least on Solaris the output of "file" on the core dump
|
|
|
|
# will not give the path, so we don't use that.)
|
2015-05-11 17:18:30 +00:00
|
|
|
#
|
2015-05-11 19:22:23 +00:00
|
|
|
if [ "$1" = "env" ]
|
|
|
|
then
|
|
|
|
#
|
|
|
|
# Skip past the env command name.
|
|
|
|
#
|
|
|
|
shift
|
|
|
|
#
|
|
|
|
# Skip past environment-variable arguments; anything
|
|
|
|
# with an "=" in it is an environment-variable argument.
|
|
|
|
#
|
|
|
|
while expr "$1" : ".*=.*" >/dev/null 2>&1
|
|
|
|
do
|
|
|
|
shift
|
|
|
|
done
|
2015-05-11 19:23:47 +00:00
|
|
|
fi
|
2015-05-11 17:18:30 +00:00
|
|
|
if [ -x "$1" ]
|
|
|
|
then
|
|
|
|
executable="$1"
|
|
|
|
else
|
|
|
|
executable=`which "$1"`
|
|
|
|
fi
|
|
|
|
|
|
|
|
if [ ! -z "$executable" ]
|
|
|
|
then
|
|
|
|
#
|
|
|
|
# Found the executable.
|
|
|
|
#
|
|
|
|
# Now, look for a debugger.
|
|
|
|
# XXX - lldb?
|
|
|
|
#
|
|
|
|
dbx=`which dbx`
|
|
|
|
if [ ! -z "$dbx" ]
|
|
|
|
then
|
|
|
|
#
|
|
|
|
# Found dbx. Run it to get a stack trace;
|
|
|
|
# cause the stack trace to go to the standard
|
|
|
|
# error.
|
|
|
|
#
|
|
|
|
dbx "$executable" core 1>&2 <<EOF
|
|
|
|
where
|
|
|
|
quit
|
|
|
|
EOF
|
|
|
|
else
|
|
|
|
gdb=`which gdb`
|
|
|
|
if [ ! -z "$gdb" ]
|
|
|
|
then
|
|
|
|
#
|
|
|
|
# Found gdb. Run it to get a stack trace;
|
|
|
|
# cause the stack trace to go to the standard
|
|
|
|
# error.
|
|
|
|
#
|
|
|
|
gdb "$executable" core 1>&2 <<EOF
|
|
|
|
backtrace
|
|
|
|
quit
|
|
|
|
EOF
|
|
|
|
fi
|
|
|
|
fi
|
|
|
|
fi
|
|
|
|
fi
|