CORE FILE
ANALYSIS - HP- UNIX
<< CONTENTS
>>
Contents:
what is a core
core file analysis
BUG report preparation
What
is a Core:
The
HP-UX system writes out a file containing a core image of a terminated
process when certain signals are received.Common causes are memory
violations, illegal instructions, floating point exceptions, bus
errors, and user-generated quit signals. To know more about core file
and it's format, use core.4 man
page.
Signal:
There are signals used to affect the application in becasuse of memory
violations, illegal instructions, floating point exceptions, bus
errors, and user-generated quit signals.
Signal
types:
To know the signal type and it's cause of rainsing
use the
singal.5 man page.Refer the /usr/include/sys/signal.h for more. Signals
which create a core image are,
Name
Default Action
Description
SIGQUIT create
core image quit program
SIGILL
create core image
illegal instruction
SIGTRAP create core
image trace trap
SIGABRT create core
image abort program (formerly
SIGIOT)
SIGEMT
create core image emulate
instruction executed
SIGFPE create
core image floating-point exception
SIGBUS
create core image bus error
SIGSEGV create core
image segmentation violation
SIGSYS
create core image non-existent
system call invoked
Core
limit:
Size of core file which is created because of abnormal behaviour of
application depends upon limit given by the system. To know the core
size limit use,
#
ulimit -c
<Number of
bytes>
#
ulimit -c
unlimited
It will be
used to give
full access to use memory,for creating the memory. It is good to keep
that the limit as unlimited!
Core file analysis:
We can use
debuggers and some command(s) to analyse it. Let us go to the core file
anaylysis:
command(s):
- file <core>
- what <core>
Debugger(s):
wdb (or) gdb:
We can
get the exact postion of source got signal or problem ,during the
execution. Stack trace will dump the core informations. We can get the
stack trace with gdb.
# gdb
<Application name> <core-file>
or
# gdb
gdb> file <Application file>
gdb> corefile <core file>
gdb> where
It will give the stack trace where the signal or problem happened.
gdb> bt
It is also do the same thing as
like where
To know the gdb command help use,
gdb > help
gdb > command <Any letter which may be
the starting letter for command>
gdb > apropos <Pattern to be
searched in the commands in gdb>
To know the signal type,
gdb> info signal
adb:
We can use the
absolute debugger to analyse the core files. It is having small set of
operations compared to gdb. Let us see adb's usage on core files
analysis.
adb <application file name> <core
file name >
adb > c
It will give the C stack backtrace.
adb> m
Initial and default maps for a valid corfil
with an indication of which is currently active
adb> ?
It will give the commands and it's usage.
BUG report preparation:
Bug report to
the developer(s) or developler list(s) must contain the stack trace
from GDB or ADB debugger to know the cause of problem and location of
source where the problem is occuring.
To report a
BUG on open source products ( taking SQUID as example ),
- Get the product configuration and compilation options.
Normally application binary with -v will all informations.
For squid, we can get it from command line as
like, <path to binay>/squid -v
Else use (elfdump -dc (IPF) ,
odump (PA-RISC) command ) or configure.* files in the source
directory.
2. Get the operating
system version and release using uname -a
command.
3. Get the log file ( syslog,product log
informations )
For squid, collect the cache.log and
/var/adm/syslog/syslog | grep squid
details
4. Finally the stack
trace and signal informations from debugger.
core analysis
are helpful to enhance and code analysis on the open source products!
CORE FILE ANALYSIS
Muthukumar
Kandasamy <[email protected]>