<p>I have a core dump file from a process that has probably a file descriptor leak (it opens files and sockets but apparently sometimes forgets to close some of them). Is there a way to find out which files and sockets the process had opened before crashing? I can't easily reproduce the crash, so analyzing the core file seems to be the only way to get a hint on the bug.</p>

[{'answer_id': 58578, 'author': 'Vinko Vrsalovic', 'author_id': 5190, 'author_profile': 'https://Stackoverflow.com/users/5190', 'pm_score': 1, 'selected': False, 'text': "<p>A core dump is a copy of the memory the process had access to when crashed. Depending on how the leak is occurring, it might have lost the reference to the handles, so it may prove to be useless.</p>\n\n<p>lsof lists all currently open files in the system, you could check its output to find leaked sockets or files. Yes, you'd need to have the process running. You could run it with a specific username to easily discern which are the open files from the process you are debugging.</p>\n\n<p>I hope somebody else has better information :-)</p>\n"}, {'answer_id': 58580, 'author': 'mweerden', 'author_id': 4285, 'author_profile': 'https://Stackoverflow.com/users/4285', 'pm_score': 2, 'selected': False, 'text': "<p>You can try using <code>strace</code> to see the <code>open</code>, <code>socket</code> and <code>close</code> calls the program makes.</p>\n\n<p>Edit: I don't think you can get the information from the core; at most it will have the file descriptors somewhere, but this still doesn't give you the actual file/socket. (Assuming you can distinguish open from closed file descriptors, which I also doubt.)</p>\n"}, {'answer_id': 58583, 'author': 'skolima', 'author_id': 3205, 'author_profile': 'https://Stackoverflow.com/users/3205', 'pm_score': 0, 'selected': False, 'text': '<p>Another way to find out what files a process has opened - again, only during runtime - is looking into /proc/PID/fd/ , which contains symlinks to open files.</p>\n'}, {'answer_id': 58606, 'author': 'Vinko Vrsalovic', 'author_id': 5190, 'author_profile': 'https://Stackoverflow.com/users/5190', 'pm_score': 2, 'selected': False, 'text': '<p>If the program forgot to close those resources it might be because something like the following happened:</p>\n\n<pre><code>fd = open("/tmp/foo",O_CREAT);\n//do stuff\nfd = open("/tmp/bar",O_CREAT); //Oops, forgot to close(fd)\n</code></pre>\n\n<p>now I won\'t have the file descriptor for foo in memory.</p>\n\n<p>If this didn\'t happen, you might be able to find the file descriptor number, but then again, that is not very useful because they are continuously changing, by the time you get to debug you won\'t know which file it actually meant at the time.</p>\n\n<p>I really think you should debug this live, with strace, lsof and friends.</p>\n\n<p>If there is a way to do it from the core dump, I\'m eager to know it too :-)</p>\n'}, {'answer_id': 59039, 'author': 'Martin Del Vecchio', 'author_id': 5397, 'author_profile': 'https://Stackoverflow.com/users/5397', 'pm_score': 3, 'selected': False, 'text': '<p>Your best bet is to install a signal handler for whatever signal is crashing your program (SIGSEGV, etc.).</p>\n\n<p>Then, in the signal handler, inspect /proc/self/fd, and save the contents to a file.  Here is a sample of what you might see:</p>\n\n<pre><code>Anderson cxc # ls -l  /proc/8247/fd\ntotal 0\nlrwx------ 1 root root 64 Sep 12 06:05 0 -&gt; /dev/pts/0\nlrwx------ 1 root root 64 Sep 12 06:05 1 -&gt; /dev/pts/0\nlrwx------ 1 root root 64 Sep 12 06:05 10 -&gt; anon_inode:[eventpoll]\nlrwx------ 1 root root 64 Sep 12 06:05 11 -&gt; socket:[124061]\nlrwx------ 1 root root 64 Sep 12 06:05 12 -&gt; socket:[124063]\nlrwx------ 1 root root 64 Sep 12 06:05 13 -&gt; socket:[124064]\nlrwx------ 1 root root 64 Sep 12 06:05 14 -&gt; /dev/driver0\nlr-x------ 1 root root 64 Sep 12 06:05 16 -&gt; /temp/app/whatever.tar.gz\nlr-x------ 1 root root 64 Sep 12 06:05 17 -&gt; /dev/urandom\n</code></pre>\n\n<p>Then you can return from your signal handler, and you should get a core dump as usual.</p>\n'}, {'answer_id': 65548, 'author': 'terminus', 'author_id': 9232, 'author_profile': 'https://Stackoverflow.com/users/9232', 'pm_score': 4, 'selected': False, 'text': "<p>If you have a core file and you have compiled the program with debugging options (-g), you can see where the core was dumped:</p>\n<pre><code>$ gcc -g -o something something.c\n$ ./something\nSegmentation fault (core dumped)\n$ gdb something core\n</code></pre>\n<p>You can use this to do some post-morten debugging. A few gdb commands: bt prints the stack, fr  jumps to given stack frame (see the output of bt).</p>\n<p>Now if you want to see which files are opened at a segmentation fault, just handle the SIGSEGV signal, and in the handler, just dump the contents of the /proc/PID/fd directory (i.e. with system('ls -l /proc/PID/fs') or execv).</p>\n<p>With these information at hand you can easily find what caused the crash, which files are opened and if the crash and the file descriptor leak are connected.</p>\n"}, {'answer_id': 27558400, 'author': 'JodieC', 'author_id': 1467450, 'author_profile': 'https://Stackoverflow.com/users/1467450', 'pm_score': 2, 'selected': False, 'text': '<p>One of the ways I jump to this information is just running <code>strings</code> on the core file. For instance, when I was running file on a core recently, due to the length of the folders I would get a truncated arguments list. I knew my run would have opened files from my home directory, so I just ran:</p>\n\n<pre><code>strings core.14930|grep jodie\n</code></pre>\n\n<p>But this is a case where I had a needle and a haystack. </p>\n'}, {'answer_id': 32613101, 'author': 'Pinak Mazumdar', 'author_id': 5343092, 'author_profile': 'https://Stackoverflow.com/users/5343092', 'pm_score': 2, 'selected': False, 'text': '<p>Recently during my error troubleshooting and analysis , my customer provided me a coredump which got generated in his filesystem and he went out of station in order to quickly scan through the file and read its contents i used the command</p>\n\n<p>strings core.67545 > coredump.txt\nand later i was able to open the file in file editor.</p>\n'}]
['https://Stackoverflow.com/questions/58564', 'https://Stackoverflow.com', 'https://Stackoverflow.com/users/2148773/']