Core generation

Archives
Thierry Reinquin

Core generation

Postby Thierry Reinquin » Wed Sep 28, 2005 1:53 pm

How does the core generation work ?
Does the OS load the memory of the process in real
memory before dumping it into the file "core" ?
Is the core generation subject to the scheduling (often time-sharing) or does it own a high priority
compared to other processes ?
Thanks for your answer !

Hermelito Go

Re: Core generation

Postby Hermelito Go » Tue Oct 04, 2005 8:38 pm

From solaris man page.

File Formats core(4)

NAME

core - core image file

DESCRIPTION

The operating system writes out a core image of a processwhen it is terminated due to the receipt of some signals. The core image is called core and is written in the process's working directory (provided it can be; normal access controls apply). A process with an effective user ID different from the real user ID will not produce a core image. This is also true for a process with an effective group ID different from the real group ID. Set-user-ID and set-group-ID programs do not produce core images either when they terminate, since this would cause a security loophole.

The core file contains all the process information pertinent to debugging: contents of hardware registers, process status, and process data. The format of a core file is object file specific.

For ELF executable programs (see a.out(4)), the core file generated is also an ELF file, containing ELF program and file headers. The e_type field in the file header has type ET_CORE. The program header contains an entry for every segment that was part of the process address space, including shared library segments. The contents of the writable segments are also part of the core image.

The program header of an ELF core file also contains entries for two NOTE segments, each containing several note entries as described below. The note entry header and core file note
type(n_type) definitions are contained in . The

first NOTE segment exists for binary compatibility with old programs that deal with core files. It contains structures defined in . New programs should recognize and skip this NOTE segment, advancing instead to the new NOTE segment. The old NOTE segment will be deleted from core files in a future release.

Thierry Reinquin

Re: Core generation

Postby Thierry Reinquin » Wed Oct 05, 2005 10:00 am

Thanks for your answer, it gives me some elements of understanding.
Actually, what I would like to know is how the kernel makes to produce the core file.
Does the kernel :
- write the hard registers and process status to the core file ?
- then load the process data in memory in order to write it in the file ? (2nd choice : as part of the process is in the swap, it could copy it from swap to the core file directly)

When are the File Descriptors closed ? At the end of the core generation ?
During the generation of the core, what is the priority of the core generation compared to other processes ? Higher ?
Or is the core generation subject to time-sharing scheduling ?

I can't find these information in the manual pages.

Hermelito Go

Re: Core generation

Postby Hermelito Go » Wed Oct 05, 2005 6:31 pm

>- write the hard registers and process status >to the core file ?

Yes, see the core struct below. (/usr/include/sys/core.h)

>- then load the process data in memory in order >to write it in the file ?

No, core files are images of a process.

>When are the File Descriptors closed ? At the >end of the core generation ?

FD are closed when the process is terminated, meaning at the end of core generation.

>During the generation of the core, what is the >priority of the core generation compared to >other processes ? Higher ?

It would get the priority of the running process.

struct core {

int c_magic; /* Corefile magic number */

int c_len; /* Sizeof (struct core) */
#ifdef _KERNEL

gregset_t c_regs; /* General purpose registers */
#else

struct regs c_regs; /* General purpose registers */
#endif /* _KERNEL */

struct exdata c_exdata; /* Executable header */

int c_signo; /* Killing signal, if any */

int c_tsize; /* Text size (bytes) */

int c_dsize; /* Data size (bytes) */

int c_ssize; /* Stack size (bytes) */

char c_cmdname[CORE_NAMELEN + 1]; /* Command name */

struct fpu c_fpu; /* external FPU state */
#if defined(sparc) || defined(__sparc)

struct fq c_fpu_q[MAXFPQ]; /* fpu exception queue */
#endif

int c_ucode; /* Exception no. from u_code */
};

Thierry Reinquin

Re: Core generation

Postby Thierry Reinquin » Mon Oct 10, 2005 1:23 pm

Thanks for your answer.
OK the core generation has got the same priority
than the process, so the process dumping will be
scheduled the same way than before dumping.

I understand also that, as the core file is image of the process, then the process has to be running to be dumped, and therefore be loaded in the real memory.
Thanks, I understand a little better.
Actually, I have a problem because I've got a huge
core of 350 Mo, and my real memory is only 256 Mo.
The core takes several minutes to be dumped.
I was wondering how it was possible, I guess
the core generation is scheduled and swapping
its memory must take time.
The only solution is to add memory (512 Mo must
be enough).
Thanks for all.


Return to “Archives”

Who is online

Users browsing this forum: No registered users and 1 guest