Core Dump File

[Keith custer]

I have a core file that I believe an applicatin created. I only just found that they exist and where to find it. I have no idea what it does or how to analyse it. The server is a H60. Just got it back up and running after replacing the main memory card.

[Steven E. Protter]

Shalom,

core file exists where the application environment decides they should go. They can provide useful information about why an application fails.

strings filename

# can get you some useful information out of the file.

Vendors like Oracle analyze these files to determine the cause of oracle failures.

SEP

[Avinash20]

Please execute the following command to find out which executable did the core

# file

where is the filename of the core.
In your case

# file core

If it show oracle or any application process, I would advice you to log a call with the Application vendor to analyze the core

[Avinash20]

You may also install the GDB on your server to get the stack trace from the core which will be useful for the application team

You could download the GDB from

www.hp.com/go/gdb

[Dennis Handly]

How old is your core file? If not recent just remove it.

Your core was truncated. About the only useful thing is:
core: core file from 'cmmload' - received SIGSEGV
Kernel: HP-UX sn42036 B.10.20 E 9000/887 ********

>SEP: strings filename
> can get you some useful information out of the file.

This is typically not that useful. At the end I see lots of:
/disk3/cmmData/P95270.812

>Avinash: You may also install the GDB on your server

I'm not sure gdb is still available for 10.20.

[Robert-Jan Goossens]

GDB is still available for 10.20.

http://mirrors.develooper.com/hpux/downloads.html

Regards,
Robert-Jan

[Dennis Handly]

>Robert-Jan: GDB is still available for 10.20.

This isn't HP's WDB.

[Keith custer]

So I got around to downloading the GDB file and got it uploaded to the server through ftp using the put command. I tried to run it as root using tar jxvf and it didn't work cause it doesn't recognize the *j* option. How do I get the GDB software installed? Do I have to install another package that will allow me to extract the GDB .tbz file?

Also all these P95270.812 files are locate in the "/disk3/cmmData" directory. They are files from another PC that get uploaded to the directory and a cron job starts the C program and compiles them into another file format and uploads those to a Database.

[T G Manikandan]

tbz2 requires bzip2 to uncompress.

http://hpux.connect.org.uk/hppd/hpux/Misc/bzip2-1.0.5/

Alternatively you can download gdb at

http://hpux.connect.org.uk/hppd/hpux/Gnu/gdb-5.3/

[Keith custer]

I got the tar version of GDB but this H60 doesn't have much of anything on it for extracting these files. Where can I get gzip or bunzip2 so I can extract and install this app. The H60 is running HP-UX 10.20.

[T G Manikandan]

Get it from here

http://www.cmve.net/merijn/downloads.html

[James R. Ferguson]

Hi Keith:

> Where can I get gzip or bunzip2

Thanks to Merijn, versions for 10.20 are available from him:

http://www.cmve.net/merijn/downloads.html

Regards!

...JRF...

[Keith custer]

Ok. I got Bzip2 downloaded bzip2-1.0.2-pa1.1

Not sure what command to use to install this on my server. Once I have this I should be able to extract tbz files.

[T G Manikandan]

The software from

http://www.cmve.net/merijn/bzip2-1.0.5-10.20.sd

should be a depot file installable using swinstall, if I am not wrong.

[Dennis Handly]

>So I got around to downloading the GDB file

Once you get gdb, have you decided what you are going to do with it? Do you have debug info in your application?

In most cases, unless you have a development machine, you just record the fact you have a core file and use file(1) to see what signal and executable. Then you remove it. If you start seeing more of them, then you do something.

"chatr cmmload" will give you a start of the list of shlibs.

You can also copy the core file and executable and ALL of the shlibs it uses to a supported machine and then use gdb there.

>all these P95270.812 files are located in the "/disk3/cmmData" directory. They are files from another PC that get uploaded to the directory and a cron job starts the C program

Is that program cmmload?
Perhaps there are too many files in cmmData to handle. Why not move half of them aside and see if it works. If they are removed after being processed, then move the other half back.

[Keith custer]

Got put on another project. Finally got back to this one. I ran the chatr cmmload command and attached a text file of it. I took the advice of the lasy=t post and removed the files and manually ran the executable. Below is the response from manually running the program.

sn42036_ORACLE72>cmmload
2 files
Memory fault(coredump)
sn42036_ORACLE72>


With that in mind, is there a command that I can run in UNIX to test the memory modules before I pick and choose what memory module is bad.

[Dennis Handly]

>I can run in UNIX to test the memory modules before I pick and choose what memory module is bad.

Why? "Memory fault" is a signal 11, which means "I'm an bad programmer and I messed up".
There is no hardware problem.

From your chatr output, you would need to copy these files to your supported OS with wdb/gdb:
cmmload
/usr/lib/libcma.1 /usr/lib/pa1.1/libcl.1 /usr/lib/libnsl_s.1 /usr/lib/libc.1

[Keith custer]

Well I'm glad to see it's not the hardware. Looks like I have to look up the person who made this program and have them fix it.