2

Is it possible to force FreeBSD to generate core files when an application/thread has a SIGSEGV==11?

I have an application that is doing this, however, i think it is just one of the threads dying, and the executable stays up running.

This executable is running as a service - where would the file be? Can I just force the core file to show up in /tmp or something?

Thanks

Derek
  • 11,715
  • 32
  • 127
  • 228

5 Answers5

2

The manpage you are looking for is core(5). You might want to set kern.corefile to a location where you are sure that you have write access and there is enough space

arved
  • 4,401
  • 4
  • 30
  • 53
1

According to man signal, a SIGSEGV should always generate a core file.

The proviso is that a core file will be generated in the current working directory, which more often than not is the working directory from when the process was started. And I'm pretty sure you can't change this behaviour. Note that some programs are launched by a shell script that changes the working directory before launching a binary, so you may be able to affect things by modifying the shell script.

According to the debugging section of the handbook, you may also be able to attach GDB to a running process.

If you'd like to collect core files in a central location like /tmp, you could run something like this in cron:

find ~ -name '*.core' -exec mv {} /tmp \;
ghoti
  • 45,319
  • 8
  • 65
  • 104
  • I am skeptical of this. Prior to posting this question i did a find on / looking for all core files and I found none, even as I was seeing the processes throw the segfaults. – Derek Jul 03 '12 at 20:01
  • Is it possible that those processes were changing their working directory to something that did not allow write permissions for the user running the processes? – ghoti Jul 03 '12 at 20:39
  • The services are running as root. Shouldn't that mean that I am able to write no matter what? Either way, I am not aware of anything that would be changing the working directory in any of the code/scripts, but I can't swear to it. – Derek Jul 03 '12 at 21:29
  • There simply isn't enough information here for me to answer your question. I can't test your code, I can't duplicate your environment. You'll need to provide more [in your question](http://stackoverflow.com/posts/11319071/edit) if you want anything more in an answer. – ghoti Jul 04 '12 at 03:58
1

What's 

# sysctl kern.coredump

output? If it's 0, then you should set it to 1, i.e.,

# sysctl kern.coredump=1
PetrosB
  • 4,134
  • 5
  • 22
  • 21
0

On Linux if I ran into this problem I would check if ulimit -c unlimited was set. This might also apply to FreeBSD. See this: How to enable core dump in my Linux C++ program

Get the pid of the process you want to kill:

ps -ef | grep process_name

Which will give you something like this:

user    PID  TID  0 etc

kill -6 PID

Make sure the process is dead, run this again, it should not show you the process like it did before.

ps -ef | grep PID

Community
  • 1
  • 1
anio
  • 8,903
  • 7
  • 35
  • 53
  • thanks - i had seen something like this before, but it doesnt solve my problem - my ulimit is unlimited – Derek Jul 03 '12 at 21:30
  • @Derek Is this a program that you wrote? Or a third party program? Does it have a signal handler installed that is ignoring sigsegv? Have you tried other signals? sigabrt? Do you have the appropriate permissions to actually kill the process? Can you verify that the process is dead after you issue the kill command? – anio Jul 03 '12 at 21:39
0

Yep, this is possible.

#include <sys/resource.h>

// core dumps may be disallowed by parent of this process; change that
struct rlimit core_limits;
core_limits.rlim_cur = core_limits.rlim_max = RLIM_INFINITY;
setrlimit(RLIMIT_CORE, &core_limits);

Also you prefer setup system coredump folder

# FreeBSD
mkdir -p /var/coredumps
chmod 777 /var/coredumps                        # for "kern.sugid_coredump=1"
sysctl kern.corefile=/var/coredumps/%U/%N.core
sysctl kern.coredump=1                          # default

For more info you can read core(5) and setrlimit(2)

disable13
  • 93
  • 1
  • 7