Very Computer

Hello, I am currently researching a situation in which a software
product terminates abnormally, but occasionally without producing a core
file...  I am trying to find all possible reasons this could occur.
The software was compiled using Sun's standard C++ compiler.
Your comments will be very helpful to me.

Thanks!
Jin

Sent via Deja.com http://www.deja.com/
Before you buy.

A process will dump a core file whenever it receives one of the signals (such
as SEGV or BUS) whose default disposition is to cause a core dump, and the
process has not installed its own handler for the signal which causes it to do
something else. The complete list is shown in signal(5). This is 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.  For
example, the process could install a handler which calls exit().

Additionally, no core dump can be created:

1. 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.

2. 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.

3. If the destination directory is part of a filesystem that is mounted
   read-only.

4. 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.

5. 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.

6. 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.

7. 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.

My apologies that this information is not in core(4) ... I'll get that fixed.

-Mike

--
Mike Shapiro, Solaris Kernel Development.

[An exhaustive list of the reasons why a core file may not be produced]

... but I think you forgot one:

Quote:>6. 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).

Or if the program was execute-only to the invoking user.

Chris Thompson
Email: cet1 [at] cam.ac.uk

Or if it effectively runs under user "nobody", and
"nobody" does not have full access rights to
the respective directory in which the core
would be produced.

Thomas