topic Re: Do core dumps really mean bad news. in Operating System - HP-UX

Do core dumps really mean bad news.

Ronald Cogen — Thu, 19 Sep 2002 07:52:56 GMT

This is perhaps a dumb question, but I will venture it anyway. Are core dumps necessarily a bad thing (especially relating to java processes)? Or can one live with them, which seems sometimes to be the case?

Greetings,
Ron

Re: Do core dumps really mean bad news.

Chris Wilshaw — Thu, 19 Sep 2002 07:57:45 GMT

The answer, as with many things is - it depends.

We have an application that dump cores at intervals. On most occasions, it almost never seems to be a major problem (sloppy coding in a database enquiry module is suspected). On the times when it is a problem, it seems to be during database writes (leading to missing/corrupt data).

The most likely problem from dropping a lot of core files is to fill up whichever filesystem it happens to be in - in our case, they tend to be dropped into /home, so we link $HOME/core to /dev/null (our application support people have no interest in analysing the cores even when we save them).

Re: Do core dumps really mean bad news.

Stefan Farrelly — Thu, 19 Sep 2002 07:57:52 GMT

I would say core dumps are bad things and should be investigated. Java is a particularly poor product in my opinion. We always have problems with it, from various core dumps to processes dying to tons of errors in the java logs requiring frequent restarts of the apps, and sometimes even the server! So in the case of Java we have to live with it too. We cannot get the provider of the app to certify we can upgrade java which means we have to live with it.

Re: Do core dumps really mean bad news.

Rainer von Bongartz — Thu, 19 Sep 2002 08:03:56 GMT

I would say core dumps are GOOD things because they show you that the software most probably is badly programmed and should be avoided or corrected.

Regards
Rainer

Re: Do core dumps really mean bad news.

Ravi_8 — Thu, 19 Sep 2002 08:09:58 GMT

Hi, Ron

I would like to say that core dumps are not bad things, it shows incorrectness in any program which creates core. Ofcourse we can live with core files ( usually we remove such files since they will be consuming the space)

Re: Do core dumps really mean bad news.

Paula J Frazer-Campbell — Thu, 19 Sep 2002 08:19:43 GMT

Ron

As has been said core dumps show problems with coding.

If you do not want to core dump to a particular directory then create a dir call "core" in that directory.

Paula

Re: Do core dumps really mean bad news.

U.SivaKumar_2 — Thu, 19 Sep 2002 08:26:26 GMT

Hi,
In a nutshell,
Core files can be accepted in Development server used in some application development.

Core files can be avoided in Production server
running standard applications for transactions.

regards,
U.SivaKumar

Re: Do core dumps really mean bad news.

Steve Steel — Thu, 19 Sep 2002 10:42:10 GMT

Hi

generally if from an application they can be lived with but should be investigated.

Use file core

This will show the program and a short what happened message

Then you know what cored and can decide for yourself a plan of action.

Steve Steel

Re: Do core dumps really mean bad news.

David Andrews_1 — Fri, 20 Sep 2002 08:43:39 GMT

If you wan to see the contents of a core file use the strings command and pipe it to page or more, EG:

strings core|pg

You may be able to tell what created the dump, but be warned it is not light reading!

I once saw a book on how to read and understand core files, but alas the place I saw this has now shut.

Most of the time core files are just an anoyance, but it would be nice to find out what caused it, to prevent it happening too often.

If you want to stop users creating core files, add the following line to your /etc/profile :

ulimit -c 0

This sets the maximum size for core files, and zero disables core file creation.

Hope this helps.

Re: Do core dumps really mean bad news.

Paula J Frazer-Campbell — Fri, 20 Sep 2002 10:41:40 GMT

Hi
To analyze core files

file
what
Strings

Also

Down load and install wdb:-

http://hp.com/go/wdb

fire up /opt/langtools/bin/gdb -c
"bt" will give a stack trace:-

(gdb) bt
#0 0xc01ecb88 in ??
#1 0xc01ecb68 in ?? ()
#2 0xc01ecb68 in ?? ()

or use "where"

There are two stored registers that will tell you the address being
accessed
and instruction the process was executing when it failed. In gdb or at
the
"(gdb)" command prompt in wdb, try:

(gdb) p /x $ior

This prints the "Interrupt Offset Register" that is the address the
program was trying to access when it failed.

(gdb) p /x $iir

This is the "Interrupt Instruction Register" that shows the machine instruction that caused the failure. To decode this start up a separate "adb" (adb) should already be installed ??? note it has no prompt and the $ prefixes each command - $q = quit) session and enter the value from the above command and follow it
with "=i". For example,

(gdb) p /x $iir
$2 = 0xfe01280

$ adb
0xfe01280=i
LDW 254,0(r31)
This is a Load word command being executed. See instructions set for PA Risc.

HTH

Paula