How do I know if these core files I found are serious???

[Shaun Aldrich]

Good afternoon everyone,

I just happened to be doing a search on 3 of my HP-UX systems today for core files and I came across the below information. One of the systems is production and the other 2 are Test & Development. How do I know if these were produced do to a serious error? The systems themselves seem to be doing fine. The notion of core files however seem to scare me. Is there anything to worry about? These files were found under /.

C1 ( Test System )

# file core
core: core file from 'midaemon' - received SIGSEGV

C2 ( Development System )

# file core
core: core file from 'midaemon' - received SIGSEGV

C3 ( Production System )

file core
core: core file from 'midaemon' - received SIGBUS

Any help or suggestions about this would be greatly appreciated...

Thanks,

S Aldrich

[James R. Ferguson]

Hi, Shaun:

The presence of occasional core files is not a great concern. If a particular process (application) frequently faults, then that is significant. Perhaps it's the fault of the application itself (poorly coded) or perhaps the termination is indicative of insufficient swap or stack space.

The use of the 'file' command against the core file provides the quick, descriptive reason for the failure. It's a good idea to do an 'ls' on the core file to make sure it is truly from the current failure. A 'what' of the core file will show you the revision of the shared libraries at the time the core file was generated.

Further analysis of the core file requires debugger tools (gdb, xdb, or dde) and the actual source code for the process(es) in question.

...JRF...

[CHRIS_ANORUO]

Hi Shaun,

Check the online manual for signal 5(man 5 signal).
The severity of the core files are explained.
I advise that you send the core file to HP engineers to diagnose this file properly.

[Shaun Aldrich]

Hi Chris / James,

I am still attempting to assign points to Chris as I am having alot of problems in the Forums today. Anytime I click on assign points beside Chris 's name I get either of the below to messages:

Error processing SSI file '/cm/QuestionAnswerContent/1,1154,LoggedIn!0x52fea14d9abcd4118fef0090279cd0f9!0!2,00.html'

404 Object Not Found

I will not forget about you.

Below is the output from the what command on core -

what core
core:
midaemon A.10.20.01 06/25/96 HPUX/MI-A =*=
ic12_r10dav_gs libc.a_ID@@/main/r10dav/libc_dav/bvd_dav/1
/ux/libc/libs/libc/archive_pa1/libc.a_ID
May 1 1996 11:43:41
9245XB HP-UX (B.10.20) #1: Sun Jun 9 06:31:19 PDT 1996

What exactly does this output mean?

Chris:

Where is the manual you are referring to that I could look up these codes?

Thanks,

S Aldrich

[Paula J Frazer-Campbell]

Hi
There are many reasons for core files some serious and some not so.
I would look closly at core files in the root directory.

The time date and ownership are important.

Your core files are produced by the midaemon:-

midaemon - HP-UX Performance Measurement Interface daemon.

Try :-
File core
What core
Strings core

To extract as much information as possible and of course investigate the midaemon .
(search the forum for midaemon)

Siglist for your info:-

SIGABRT Process abort signal.
SIGALRM Alarm clock.
SIGFPE Erroneous arithmetic operation.
SIGHUP Hangup.
SIGILL Illegal instruction.
SIGINT Terminal interrupt signal.
SIGKILL Kill (cannot be caught or ignored).
SIGPIPE Write on a pipe with no one to read it.
SIGQUIT Terminal quit signal.
SIGSEGV Invalid memory reference.
SIGTERM Termination signal.
SIGUSR1 User-defined signal 1.
SIGUSR2 User-defined signal 2.
SIGCHLD Child process terminated or stopped.
SIGCONT Continue executing, if stopped.
SIGSTOP Stop executing (cannot be caught or ignored).
SIGTSTP Terminal stop signal.
SIGTTIN Background process attempting read.
SIGTTOU Background process attempting write.
SIGBUS Bus error.
SIGPOLL Pollable event.
SIGPROF Profiling timer expired.
SIGSYS Bad system call.
SIGTRAP Trace/breakpoint trap.
SIGURG High bandwidth data is available at a socket.
SIGVTALRM Virtual timer expired.
SIGXCPU CPU time limit exceeded.
SIGXFSZ File size limit exceeded.
SIGRTMIN First realtime signal.
SIGRTMAX Last realtime signal.


HTH

Paula

[James R. Ferguson · Accepted solution]

Shaun:

The manual to which Chris refers are the "man" pages, in this case, section-5. Look at the man(ual) pages for 'kill' and 'what' [section-1], 'core' [section-4] and 'signal' in section-5. Note that the 'volume' in which the various sections occur is different in 11.x than in 10.x -- five volumes comprise 11.x whereas only four make up 10.x. For 'signal (5)' is section-5 in volume-4 for 10.x but volume-5 for 11.x.

# man 1 kill
# man 1 what
# man 4 core
# man 5 signal

If these core files from the midaemon are being produced with regularity, then as Chris suggested, send them on to HP for analysis.

You might also see if you have the man pages for 'midaemon' on your server:

# man 1 midaemon

Check, for errors too, in: /usr/perf/log//midaemon.err

...JRF...

[Victor BERRIDGE]

Hi Shaun,
I would add, if you have cores on different machines with the SAME timestamp then you should investigate, a quick one would be to:
strings core

You could find out (like me, I had the case...) someone is looking for exploits...

Best regards
Victor

[Bill Hassell]

The midaemon needs to be updated. There are a number of past causes (mostly very busy systems) that can cause midaemon to core dump. Get the latest midaemon patch for your system.

[Bill McNAMARA_1]

I believe a segment violation signal is
because the app is trying to allocate
more memory than the kernal default tolerance.
I believe the exact parameter is maxdsiz
but that'll depend on 10.20 and 11.

I read a relatively good doc that described
hpux tuning on hp-partners.com but lost
the link..

Good luck anyway,
Bill