core file from 'cp' - received SIGSEGV

[shardam]

Hi everyone,

Can someone help to shred light about this core file generated if this is a serious problem. Here's the output from the debugger tool that I got from this core file.

HP gdb 3.3 for PA-RISC 1.1 or 2.0 (narrow), HP-UX 11.00.
Copyright 1986 - 2001 Free Software Foundation, Inc.
Hewlett-Packard Wildebeest 3.3 (based on GDB) is covered by the
GNU General Public License. Type "show copying" to see the conditions to
change it and/or distribute copies. Type "show warranty" for warranty/support.
..(no debugging symbols found)...
Core was generated by `cp'.
Program terminated with signal 11, Segmentation fault.
(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...#0 0x692f6268 in ?? ()
(gdb) bt
#0 0x692f6268 in ?? ()
warning: Attempting to unwind past bad PC 0x692f6268
#1 0x692f6268 in ?? ()
#2 0x692f6268 in ?? ()
#3 0x692f6268 in ?? ()
Cannot access memory at address 0x2f70726f


What was the caused behind this core file generated after initially cp command initiated but second time works fine.

Thanks in advance.
Alfred

[shardam]

based from the output of file cmd gave me this mssg:

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

[Matti_Kurkela · Accepted solution]

The debugger says "no debugging symbols found", so you would need to understand PA-RISC assembler language to get useful information out of this core dump. HP might have the necessary debugging symbol files, but 11.00 is out of support, so they might not want to help you.

Use "what /usr/bin/cp" to identify the patch level of the cp command: this might offer some clues.

If you invoked that "cp" command with exact same parameters and the first try failed but the second one succeeded, I would suspect data corruption in memory or in the CPU. Does this machine have any other strange intermittent problems?

What's the hardware model? (i.e. what does the "model" command report?)

Use the STM diagnostics (stm/mstm/xstm according to your UI preference) to check memory and CPU error counts. If this machine has a GSP, check its log for applicable error messages. These might allow you to identify the failing memory module or CPU.

MK

[Dennis Handly]

If the same thing works later, you just may want to ignore it.

The version of gdb that you have is obsolete. It may be responsible for the bogus stack trace.
Also 0x692f6268 could indicate stack corruption since that is the string "i/bh"
$1 = 105 'i'
(gdb) p /c 0x2f
$2 = 47 '/'
(gdb) p /c 0x62
$3 = 98 'b'
(gdb) p /c 0x68
$4 = 104 'h'

[Laurent Menase]

Hi,
1st check dmesg
2nd contact hp hardware support to check hardware logs.

[shardam]

Hi MK and dnnis

Thanks for your reply. currently my gdb version Im using is HP gdb 5.7 for PA-RISC 1.1 or 2.0 (narrow), HP-UX 11.00, the one on the above I used from test server and core dump file w/c i just uploaded. If 11.00 is already out of support from HP, is it possible we can upgrade this WDB tool to the latest one?

Im also thinking it might be from the patch level of the cmd and currently it using PHCO_34832.

So far I do not encounter any issues from the system yet and even before. And I did check the memory and cpu from stm but they wre seems running fine with no error logs found. Anyway fyi, the model of the server is rp8420.

[shardam]

hi laurent,

no even erros gave me from dmesg and syslog. I would normally only raise a hardware call if there's really a hardware problem from the system.

Thanks for your share...

[Dennis Handly]

>currently my gdb version I'm using is HP gdb 5.7 for PA-RISC 1.1 or 2.0 (narrow), HP-UX 11.00, the one on the above I used from test server and core dump file w/c i just uploaded.

You can't debug core files on a different system than the one that created it.
(You can use packcore & unpack core. Or you must copy the core, the executable and every shlib that is used. Then use GDB_SHLIB_PATH to point to the directory where you copied the files.)

>If 11.00 is already out of support from HP, is it possible we can upgrade this WDB tool to the latest one?

You could try, at least newer than 3.3.

>So far I do not encounter any issues from the system yet

Then I wouldn't worry unless it repeats.