SIGSEGV corefile

[Paul Glass]

I am getting SIGSEGV crashes from a C program, and have been unable to trace the code responsible. It does not produce a corefile. Is there a way I can force it to produce a core so that I can examine it in gdb?

[Peter Godron]

Hi Paul,
and welcome to the forums !

What is your ulimit -c, as to disable core:
ulimit -Sc 0

On Core files:
http://forums1.itrc.hp.com/service/forums/bizsupport/questionanswer.do?threadId=728058

On SIGSEGV debugging:
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=703638

Please also read:
http://forums1.itrc.hp.com/service/forums/helptips.do?#33 on how to reward any useful answers given to your questions.

[A. Clay Stephenson]

While you can force a core dump via the abort() function, the core image will be of no value to you because it is not related to the cause of your current crash. First, has the your applications's default signal handler for SIGSEGV (which should produce a core file) been replaced or disabled? Next do a man 5 signal and look for the SIG_DFL section. The conditions which must be met for a core file to be produced are listed. I'll bet that one of them is not being met.

[Dennis Handly]

>Is there a way I can force it to produce a core so that I can examine it in gdb?

If you can run it in gdb, it will stop on the signal. That may be easier to debug.

[Paul Glass]

First of all, thank you all for your help.

ulimit -c is 4194303. That should be plenty.

We do have signal handlers, to ensure DB transactions are rolled back, etc. But on the system we're migrating from (not HPUX) they still produce a core. This is not so with HPUX?

I did try my own signal handler, which called alarm(), but no core was produced.

I also tried running it in gdb. It stopped on the signal, but with the call stack replaced by one since the signal was received (about three system/runtime type functions named something like __sig_sys()).

[Dennis Handly]

>But on the system we're migrating from (not HPUX) they still produce a core. This is not so with HPUX?

No, that's why they are called handlers. What do you do at the end of it? Do you exit or abort? Do you call longjmp? Or do you return?

The latter is most likely to get you into an infinite loop if you have rearmed the handler. If not, you should get a core file.

>It stopped on the signal, but with the call stack replaced by one since the signal was received (about three system/runtime type functions named something like __sig_sys())

Please provide the exact output. This should allow you to use the frame command to inspect the frame where you are getting the signal.

[Paul Glass]

Thanks all who offered solutions. It was very straight-forward really. I just did "signal(SIGSEGV,SIG_DFL)" to revert to default behaviour.

The system We're migrating from produces a core despite our signal handlers, and we have to call ulimit in /etc/profile

[Paul Glass]

Problem solved