0

Currently, I run a Java program will call some C++ library, and I find that after some files have been deleted, there still some thread holds the fd such as

3515991655    0 lr-x------   1 user     group         64 Jul 29 10:52 /proc/81263/fd/658 -> /path/to/file.suffix\ (deleted)

I can use lsof to find which process holds the FD(for reading purpose) and can find out the thread id, but I still didn't find out what code holds the FD.

my question: is there any way I can find out the stack which holds the open FD? so that I can find out the code leads the problem

user534289
  • 9
  • 1
  • @anx yes, there is someone still _keep_ these file descriptor(the file was deleted, but the file descriptor is kept), but currently, I can't find out who _holds_ the file descriptor. I went through the Java code, but can't find who _kept_ the file descriptor, the C++ library is implemented by others, and they do not have much time on this problem, so I want to figure it out the stack which holds the file descriptor. – user534289 Aug 05 '19 at 05:44

1 Answers1

0

You could attach to the process with gdb and check the stack that way:

gdb /proc/81263/exe 81263
(gdb) bt
#0  0x00007f73808279a4 in __GI___nanosleep (requested_time=0x7ffef777b730, remaining=0x0)
    at ../sysdeps/unix/sysv/linux/nanosleep.c:28
#1  0x000055c7acccca44 in ?? ()
#2  0x000055c7acccc840 in ?? ()
#3  0x000055c7accc9aac in ?? ()
#4  0x00007f7380764b97 in __libc_start_main (main=0x55c7accc98d0, argc=2, argv=0x7ffef777b8f8, init=<optimized out>, 
    fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffef777b8e8) at ../csu/libc-start.c:310
#5  0x000055c7accc9b9a in ?? ()
Matt Zimmerman
  • 371
  • 1
  • 10