Very Computer

I've been asking around my department and can't get a good answer,
maybe someone here can help.

I'm in a groupware development project in which we will typically have
3 or more processes running and communicating with each other.  Then
one program will crash resulting in another one of the programs
crashing.  There is a core file, but it inevitably ends up being the
dump of the _second_ crash, not the first.

My question is this: Why should all core files be "core"?  I can't
believe this is the first time anyone has had this problem.  The best
answer I've gotten is "It's just a holdover from the old days."  Even
it you are debugging only one program, I'd rather generate several
cores, then go and look at them.  It's annoying to have to keep moving
them or changing its name to something unique..

Would it be hard to change things so that the name would be "core.PID"
where PID is replaced by the pid of the crashing program?  It seems
like a very small change, to me, but I'm no kernel hacker.

If Linux could do this it would be a big win.  Most of our development
is on Solaris and IRIX and this would give Linux something that I
could really sell to the rest of the development group.

What do you think?  Am I way off base about the dificulty of
implementing this?

--
Michael D, Hirsch                       Work: (404) 727-4969
Emory University, Atlanta, GA 30322     FAX: (404) 727-5611

Public key for encrypted mail available upon request (or finger

Quote:

>Would it be hard to change things so that the name would be "core.PID"
>where PID is replaced by the pid of the crashing program?  It seems
>like a very small change, to me, but I'm no kernel hacker.

>What do you think?  Am I way off base about the dificulty of
>implementing this?

        memcpy(corefile,"core.",5);
#if 0
        memcpy(corefile+5,current->comm,sizeof(current->comm));
#else
        corefile[4] = '\0';
#endif

I'm not a kernel hacker either (not much anyway), but it looks like this
was an attempt to add the command name to the corefile name, so for example,
if top coredumped you would get core.top, dont yell at me if your machine
crashes  =), but this would probably do what you want:

        memcpy(corefile,"core.",5);
#if 1
        memcpy(corefile+5,current->pid,sizeof(current->pid));
        corefile[6+sizeof(current->pid)] = '\0';
#else
        corefile[4] = '\0';
#endif

--
    Jason Kohles -- System Administrator -- XMission Internet Access

       "We're not surrounded, we're in a target-rich environment!"

: My question is this: Why should all core files be "core"?  I can't
: believe this is the first time anyone has had this problem.  The best

it's just a holdover from the old days.  :-)

freebsd names their cores as "core.<progname>" which i find pretty useful.

core.pid would be too, but probably both, i.e. "core.<progname>.pid" would
be better.

and of course it should be configurable.  some people may want the old
behavior until their core cleanup scripts are updated, for instance.

paul
--
=---------------------

  Michael> My question is this: Why should all core files be "core"?

It makes them easier to clean up with "find" and it's traditional.

  Michael> I can't believe this is the first time anyone has had this
  Michael> problem.  The best answer I've gotten is "It's just a
  Michael> holdover from the old days."  Even it you are debugging
  Michael> only one program, I'd rather generate several cores, then
  Michael> go and look at them.  It's annoying to have to keep moving
  Michael> them or changing its name to something unique..

  Michael> Would it be hard to change things so that the name would be
  Michael> "core.PID" where PID is replaced by the pid of the crashing
  Michael> program?  It seems like a very small change, to me, but I'm
  Michael> no kernel hacker.

Take a look at elf_core_dump() in linux/fs/binfmt_elf.c.

Depending on details of your program, that may be a solution (if so,
it would be portable, of course).

Nothing wrong with simply making this choice at Linux
build time (as folks suggested) though. IMO.

In addition, while it is not very advisable, you could catch the SIGSEG, SIGBUS,
and SIGABRT signals and determine if you want a core dump.  If so, call the
abort() function; otherwise, just exit().

Of course, if you do decide to modify the kernel, make sure that you do NOT
memcpy(..., pid, sizeof(pid)) because pid is an integer which means the name
of the core file will not be "core.12345", but will be "core.<garbage>".
Perhaps try:

static char buffer[16];

sprintf(buffer, "%d", pid);
memcpy(..., pid, strlen(buffer));

hope this helps

Quote:

> FYI:
> The IRIX approach is to have a system-wide kernel 'variable'
> (you must be root to change it).  Using the systune(1) command,
> interactively change the 'variable' corepluspid to 1.  Then the
> core file has . and the the PID appended to the name when a
> coredump occurs.    No kernel rebuild needed.

Thanks to all who replied,

--
Michael D, Hirsch                       Work: (404) 727-4969
Emory University, Atlanta, GA 30322     FAX: (404) 727-5611

Public key for encrypted mail available upon request (or finger

--
Michael D, Hirsch                       Work: (404) 727-4969
Emory University, Atlanta, GA 30322     FAX: (404) 727-5611

Public key for encrypted mail available upon request (or finger

In newsgroup: comp.os.linux.development.system

Quote:

> FYI:
> The IRIX approach is to have a system-wide kernel 'variable'
> (you must be root to change it).  Using the systune(1) command,
> interactively change the 'variable' corepluspid to 1.  Then the
> core file has . and the the PID appended to the name when a
> coredump occurs.    No kernel rebuild needed.

> Nothing wrong with simply making this choice at Linux
> build time (as folks suggested) though. IMO.

        -hpa
--
    PGP: 2047/2A960705 BA 03 D3 2C 14 A8 A8 BD  1E DF FE 69 EE 35 BD 74
    See http://www.zytor.com/~hpa/ for web page and full PGP public key
        I am Bah' -- ask me about it or see http://www.bahai.org/
   "To love another person is to see the face of God." -- Les Misrables

I think this came from the sys-admins camp - you know the guy works late
all the time and cleans up files after programmers dump them with
_poor_  coding habits - it is really great that it is named core -
otherwise - let me see - in the one of current project I got, each core
= 250 MB - programmer compiles and runs the app about 4 times an hour -
so that is 1 GIG/hr. It is my good luck that all of them work from 9 to
5 sharp with 1 hr lunch etc. - so I get 7 gig / day worth of core files
from 1 developer - there are 5 developers in a team .... go figure !!

: I've been asking around my department and can't get a good answer,
: maybe someone here can help.
: Would it be hard to change things so that the name would be "core.PID"
: where PID is replaced by the pid of the crashing program?  It seems
: like a very small change, to me, but I'm no kernel hacker.
: If Linux could do this it would be a big win.  Most of our development
: is on Solaris and IRIX and this would give Linux something that I
: could really sell to the rest of the development group.

I've banged around on at least one unix (NetBSD?) that dumps to
argv[0].core, which might be a better solution.  (Maybe argv[0].core.PID?)
The only problem I can see is with automated clean-up scripts
or clean: lines in Makefile that assume all corefiles are named ``core''.
--

  PERTH -> _|*~-  http://www.math.ttu.edu/~kesinger/     McQ
           \,  _} ``Although we have no quarrel with you, we *are* Samurai and
             \(     *will* give you what for.'' Miaowara Shimura. (Mark Rogers)

        Stefan

Quote:> core.pid would be too, but probably both, i.e. "core.<progname>.pid"
> would be better.

To look nice:  progname.core

To be modern: progname.sdram

For the kernel config:
Memory type (tube, mercury, crt, core, sram, dram, sdram) [sdram]

Quote:> The only problem I can see is with automated clean-up scripts
> or clean: lines in Makefile that assume all corefiles are named ``core''.

        Stefan