Core Dump - Received SIGSEGV

[Joseph C. Denman]

I have an application that I am getting core dumps.

sh: 16738 Memory fault(coredump)

core: core file from 'CU1C2020.e' - received SIGSEGV

This just started, and I am thinking it may be a kernel parameter. Does anyone have an idea? The search function on this sight is not working????

Thanks,

...jcd..

[John Guster]

review the output of "strings core", it might give more detailed message.

[Sandman!]

Did you tune any of the memory-related kernel parameters like max[dts]siz, shmseg, shmmni, shmmax etc. ?

[Joseph C. Denman]

We have not changed any kernel parameters. The appliction receiving the core dump handles one of our interface partners. We have added many mailboxes the past week or two?

Looking at the core file did not reveal any issue????

...jcd...

[Heironimus]

A segfault is most often a programming error, generally either in memory management or input processing. If it's an in-house application the development group should analyze the core dump with a debugger (gdb, ddd, wdb, or whatever you use internally). If it's something you bought you should probably contact the vendor.

I think the only time I've seen frequent segfaults that weren't caused by a programming error was when I had an incompatible version of a shared library. That can happen with an update, or a bad SHLIB_PATH/LD_LIBRARY_PATH setting. In either case, you should know if you did it recently.

[A. Clay Stephenson]

Running the strings command on a core file will tell you almost nothing. It can reveal potential error messages (ie, if there is a table of error possible errors, it can display the entire table as well as any other strings such as "Please enter your name" which might be embedded in the object code) but strings will tell you absolutely nothing about the specific error.

A far better approach is to use a debugger such a gdb on the core file to get a stack trace --- but even here without the source code, the stack trace will be of limited value.

It is possible that because of more activity or larger data volumes you are hitting kernel limits (most likely maxdsiz or possibly maxssiz. Don't get carried away and expand maxssiz by huge margins (32MiB is normally more than sufficient) and if this is 32-bit code, increasing maxssiz can literally be robbing Peter (data segment limited by maxdsiz) to pay Paul (the stack) because both are allocated from the same quadrant.

[Dennis Handly]

As Clay and Heironimus have mentioned, you need to use gdb on the executable and core file to get a stack trace. That may give you some clue to your problem.

You can download gdb from:
http://www.hp.com/go/wdb

In general, you invoke it by:
gdb executable corefile-name

About the only case it can be a kernel parm is a stack overflow, which has a different message. A thread stack overflow. Or running out of heap space and not having error checks when malloc returns an error.