Core file creation

[William R Bowen]

Does a user have the ability to create a core file or is it just from system calls and application. If the user can do this, is there a command to identify the user?

[Robert-Jan Goossens]

Hi David,

No normaly not. But I've seen susers using the name core for files.

Regards,
Robert-Jan

[Stephen Keane]

If a running process doesn't have certain signals trapped, and a user can send one of those signals to the process, and the default action for the signal is a core dump, then a user can indeed create a core file.

See man 5 signal for details of signals that by default can generate a core file.

e.g. SIGABRT, SIGQUIT, SIGSEGV

kill -SEGV pid

[Sameer_Nirmal]

A core file can't be generated by a user directly . In fact , the core file contains the core image of the terminated process. Now a process always runs under what we call as real user ID , which say whomsover user ID is running that process. Thereafter if a process terminates, the system creates a core file depending on bus errors , memory violations or user generated signals.
So if some user signals are defined in the executables , which make a way to creat core file depending on error encountered.

You can check which process the core file belongs using # file

[A. Clay Stephenson]

The most common means (and indeed what the abort() function does) is to send a SIGABRT to a process. The default action for SIGABRT is to generate a core file.

Generally all that is necessary is to send a kill -6 PID to a process although the signal may be caught and not necessarily generate a core file. Man 5 signal for a good explanation of signal handling.

[Bill Hassell]

I think Clay might have meant kill -3 rather than -6. Here's an example for any user to generate a core file:

sleep 500 &

(make note of the PID - we'll assume it is 4321)

kill -3 4321
ll core
file core

and now you have a core file. Any program can generate a core file so if a user is logged in, there is the possibility for generating a core file. Technically, HP-UX generates the file in response (mostly) to bad programming, so if you're wondering why users have core files in their directories, the answer is found by using the file commmand. file will decode the code file as to it's name and reason for the core dump.

NOTE: If you don't get a core file, use ulimit -a to see if your sysadmin has removed the ability using ulimit -c 0.

[A. Clay Stephenson]

Actually I did intend kill -6 (SIGABRT) so that the abort signal would be sent emulating
as closely as possible the abort() function. However, since the default action of both SIGABRT (-6) and SIGQUIT (-3) is to generate a core file, either should work although it is far more common for SIGQUIT to be caught (or ignored) than SIGABRT.

[Steven E. Protter]

If relavent, you can prevent core dumps with the following line in /etc/profile or user profile.

ulimit -Sc 0

Interesting discussion.

SEP

[Muthukumar_5]

Based on KILL Signals applications are getting signal and creating core files. Core file creation is done based on the user limit setting of -c option as,

# ulimit -c
# ulimit -Hc (hard limit)
# ulimit -Hc (soft limit)

To set it unlimited then,

# ulimit -HSc unlimited

Following sigals will create core files based on ulimit -c option as,

Default
Signal Action Description

SIGABRT ii Process abort signal.
SIGFPE ii Erroneous arithmetic operation.
SIGILL ii Illegal instruction.
SIGQUIT ii Terminal quit signal.
SIGSEGV ii Invalid memory reference.
SIGBUS ii Bus error.
SIGSYS ii Bad system call.
SIGTRAP ii Trace/breakpoint trap.
SIGXCPU ii CPU time limit exceeded.
SIGXFSZ ii File size limit exceeded.

You can analyze core file as,

# file core
# what core
# gdb core
gdb) bt
# adb core
adb) $c

hth.