gcc debugging, Segmentation Fault (core dumped) but no core

c, debugging, gcc

Solution

As @JonathanLeffler noted, the core dump goes in the current directory.

You can use `strace` to see if the process has done a chdir(). Unfortunately `strace` does not show where the core dump itself went, but:

$ cat crash.c
int main(void) {
    chdir("/tmp");
    *(int *)0 = 0;
    return 0;
}
$ cc -o crash crash.c
$ strace ./crash
execve("./crash", ["./crash"], [/* 53 vars */]) = 0
... [lots of libc trace stuff snipped] ...
chdir("/tmp")                           = 0
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0} ---
+++ killed by SIGSEGV (core dumped) +++
Segmentation fault
$ ls /tmp

and there is now a core.pid file in there.

Problem

It used to be that I would get `Segmentation Fault` with no core, then I added -ggdb to the compile command and executed this command in bash prior to executing gcc: ``` ulimit -c unlimited ``` All was good for a while (I got a core), but now I get `Segmentation Fault (core dumped)` but no core in the directory where gcc command was issued? Could it be going somewhere else? What else can I try? A little additional info: - OS: Gentoo Linux - Enable ELF core dumps is enabled in the running kernel. - The application is a text editor written in gtk+ Answer: I found it two ways: - `find / -name "core" -ls` As torek suggested: $ strace ./executable > output.txt 2>&1 $ grep chdir output.txt

Original source