> I am running Solaris 2.6. One of our routines is getting a SIGSEGV.
> I cannot find a core file on the system. Is there something I need
> to turn on. Thanks for any help..
to the running process to obtain a stacktrace.
Check your 'limit' or 'ulimit' for coredumpsize. Dumps are disabled if
that is set to 0.
Unix System Administrator Taos - The SysAdmin Company
Got some Dr Pepper? San Francisco, CA bay area
< Please move on, ...nothing to see here, please disperse >
> Sent via Deja.com http://www.deja.com/
> Before you buy.
check your setting, make sure that you uncomment it
## Default is to not do a savecore
if [ ! -d /var/crash/`uname -n` ]
then mkdir -m 0700 -p /var/crash/`uname -n`
echo 'checking for crash dump...\c '
savecore /var/crash/`uname -n`
>Sent via Deja.com http://www.deja.com/
>Before you buy.
Cherry> On solaris 2.6, savecore is turned off by default
That has nothing to do with core files from user programs, but is
whether you want to save a core of the kernel if/when it crashes.
It is turned off by default, because a new file is created each time.
If an installation has a problem that makes the system crash, these
files would quickly fill up available space on that volume.
Again, this has nothing to do with the question at hand, however.
>> I am running Solaris 2.6. One of our routines is getting a SIGSEGV.
>> I cannot find a core file on the system. Is there something I need
>> to turn on. Thanks for any help..
The program will dump a core file whenever it receives one of the signals (such
as SEGV or BUS as you mention) whose default disposition is to cause a core
dump, and the application has not installed its own handler for the signal
which causes it to do something else. The complete list of default signal
dispositions is shown in signal(5). This is the first and most obvious way
in which an application will not produce a core file -- by blocking or
modifying the behavior of a signal which by default produces a core.
Additionally, no core dump can be created:
- If the resource limit RLIMIT_CORE has been set to 0 for the process.
Refer to setrlimit(2) and ulimit(1) for more information on resource limits.
- If the file "core" exists in the destination directory and is not a regular
file (i.e. is a symlink, block or character special-file, etc). If your
system has coreadm(1M), this test is applied to both the global pathname and
the per-process pathname.
- If the destination directory is part of a filesystem that is mounted
- If the file "core" exists in the destination directory and is not writeable
to the user-id associated with the process trying to dump core. If your
system has coreadm(1M), this test is only relevant to the per-process core
file pathname, because the global core file is always written as the super-user.
- In Solaris 7 and later, if the kernel cannot open the destination file
O_EXCL, which might happen if another process is trying to dump core there at
the same time.
- If the process is setuid or setgid or has changed its uid or gid (by virtue
of being root and executing any of the set*id(2) system calls). In Solaris 7
and later, these processes can be granted permission to dump core (at the risk
of compromising secure data) by setting "allow_setid_core" to 1 in /etc/system
or via adb -kw. In Solaris 8 or later, or in a recent Solaris 7 Update,
these processes can be granted permission to dump core using the new
coreadm(1M) utility instead.
- If the system has coreadm(1M), the global core file and per-process core
file will not be written if the corresponding expanded pathname contains
intermediate directory components that do not exist. For example, if you set
your global pathname to "/var/core/%n/core.%p", and you have not created the
directory /var/core/`uname -n`, no global core files will be produced.
Mike Shapiro, Solaris Kernel Development.
We use gcc 2.5.8 and gdb 4.13 on Solaris 2.3. Some of our applications
say they dump core on a SEGV (or some other error) and running a
'file core' indicates that they did. However, the core file size
is only 800K+ and when loaded into gdb, an error indicating that the
core file is of incorrect format is displayed. We have recently
implemented threads usage in our code. Could this be contributing
to our "core" file problem? Is there a solution or workaround?
Core files are an essential debugging aid.
Marquette Electronics, Inc. CompuServe: 71064,1202
8200 W. Tower Ave.
Milwaukee, WI 53223 Jimmy the 'C'
Toll-free: (800) 558-5120 x3628
Direct: (414) 362-3628 "I protest, I am not a merry man!"
Fax: (414) 357-5947 -- Lt. Worf