1

1) Have problem with my daemon. Its crashed time to time without core dumb generation. system is FreeBSD. Before always .core was generated. Seems this is some other kind of error or something other happens and its exit without core. Anyway I want to know this and fix!

2) How to check on freebsd that core must 100% sure be generated? here: How to generate a core dump in Linux when a process gets a segmentation fault? says that ulimit -c unlimited but Command not found

3) Seems to catch the error/crash I need to attach to the process with GDB? How to do that? Also searched at stackoverflow and founded: gdb attach to a process without stop but i am note sure that I do all right:

a) I make the file called attach give his rights to execute and add this lines:

 echo "cont" > attach.gdb
 gdb server $1 -x attach.gdb
 rm attach.gdb

b) run like ./attach and its started, but I can not do nothing. Its right? I need to wait before daemon will crash and than write generate-core-file to get core?

4) Will core be generated by command generate-core-file if daemon exit without SEGFAIL or other exception ?

thanks and sorry for my english. Its hard to write some big messages on not native language. You must to understand...

Community
  • 1
  • 1
abrahab
  • 2,430
  • 9
  • 39
  • 64

2 Answers2

1

3b) you need to run ./attach 1234 where 1234 is the PID of the running process (that PID will be the $1 argument to the script, which will be passed to gdb)

Or just don't bother with that attach script (it's pretty pointless) and run gdb server 1234 then type the command cont and wait for it to crash.

If it crashes while gdb is attached to it, why do you need a core file? The benefit of a core file is using a debugger to examine it, but if it crashes inside the debugger then just debug it directly, you don't need a core file! So forget about generate-core-file and when it crashes examine the process directly.

Jonathan Wakely
  • 166,810
  • 27
  • 341
  • 521
  • thanks, but it would be useful always have .core file, because i can not monitor daemon under gdb all day long. and you know "dad things happen when you do not expect them" and at the most inopportune moment – abrahab May 17 '12 at 21:14
  • 1
    You don't need to monitor it, you could just leave it running, but it will run much slower under gdb, and stop if any signals are raised. I was only answering 3 and 4 about using gdb. To find out why you get no core file find out what the exit status of the daemon is when it exits (maybe by running it from a script and printing $? after it exits) and find out why there's no core file (maybe it's run from a directory where it doesn't have permission to write a file) – Jonathan Wakely May 17 '12 at 21:42
  • can you add step-by-step instruction of how to get the exit status? somethings like at my question create shell file with ./server | echo $ > status.file ? ps. no, its writed .core later on SIGFAIL.) – abrahab May 17 '12 at 21:54
  • 1
    ./server ; echo $? > status.file – Jonathan Wakely May 17 '12 at 22:24
1

If your process didn't core because of a ulimit problem, write a tiny shell script that sets ulimit before running your process:

#! /bin/sh
ulimit -c unlimited
/path/to/my/program > program.out 2>&1
echo $? >> program.out

This lets you capture the stdout and stderr from your program, and to capture the programs return status into program.out. You will have to watch the size of this file, if it fills up the filesystem it resides on that can lead to other badness.

It's not a given that this is why you didn't get a core, though. If your program was compiled for debugging and hit an assert(), it will exit without coring. Does your program print anything or log anything before exiting?

Wexxor
  • 1,919
  • 1
  • 15
  • 17