Community
Participate
Working Groups
Created attachment 170038 [details] file descriptor leak It looks like the attack to process launch is leaking file descriptors which can make Eclipse unusable. The attachment shows ls -l of the /proc/<java_pid>/fd. It shows filedescriptors still open to elsewhere in the proc tree. I had previously used the DSF attach to process launcher, so I'm guessing it's this that's looking at cmdline.
What are the steps to do this? When I try an DSF-GDB attach on a Linux 32, I just get > ls -l /proc/10933/fd/ total 3 lrwx------ 1 lmckhou lmc_x 64 2010-05-26 14:26 0 -> /dev/pts/1 lrwx------ 1 lmckhou lmc_x 64 2010-05-26 14:26 1 -> /dev/pts/1 lrwx------ 1 lmckhou lmc_x 64 2010-05-26 14:26 2 -> /dev/pts/1
I get this just starting an attach launch. These issues tend to be very JVM dependent. While file descriptors are closed during garbage collection, as garbage collection is triggered by memory pressure the clean-up can be infinitely delayed. I'm guessing whatever in the attach dialog opens cmdline doesn't explicitly close the input stream. I can dig a bit deeper; the fix is usually trivial.
Created attachment 170078 [details] proposed patch ProcessList never closes the FileReader which leaks file descriptors. Simple fix attached, will give it a go tomorrow when I'm back on Linux.
Wow, that's a old bug. There is a similar class in the win32 plugin which creates an InputStreamReader. Should that one also call close()?
Created attachment 170158 [details] patch 2 (In reply to comment #4) > Wow, that's a old bug. > There is a similar class in the win32 plugin which creates an > InputStreamReader. Should that one also call close()? Yes, they all should. It's much less bad here though, as we're only leaking one process worth of filedescriptors (per query), rather than one file descriptor for every process on the system. I did some tracing through DSF (so many layers!) and it looks like it only falls back to these core methods when GDB doesn't list the processes (GDBProcesses_7_0#getRunningProcesses). So this issue is most observable using CDI. I've been through all the ProcessLists and ensure that filedescriptors and close()d and processes destroy()d. I think it's pretty straightforward, but do review and shout if you see anything untoward!
Committed. Marc if you could give it a look over, that would be appreciated.
*** cdt cvs genie on behalf of jblackburn *** [!] ProcessList.java 1.8 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt-core/org.eclipse.cdt.core.linux/src/org/eclipse/cdt/internal/core/linux/ProcessList.java?root=Tools_Project&r1=1.7&r2=1.8 [!] ProcessList.java 1.7 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt-core/org.eclipse.cdt.core.aix/src/org/eclipse/cdt/internal/core/aix/ProcessList.java?root=Tools_Project&r1=1.6&r2=1.7 [!] ProcessList.java 1.13 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt-core/org.eclipse.cdt.core.win32/src/org/eclipse/cdt/internal/core/win32/ProcessList.java?root=Tools_Project&r1=1.12&r2=1.13 [!] ProcessList.java 1.8 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt-core/org.eclipse.cdt.core.solaris/src/org/eclipse/cdt/internal/core/solaris/ProcessList.java?root=Tools_Project&r1=1.7&r2=1.8 [!] ProcessList.java 1.7 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt-core/org.eclipse.cdt.core.qnx/src/org/eclipse/cdt/internal/core/qnx/ProcessList.java?root=Tools_Project&r1=1.6&r2=1.7 [!] ProcessList.java 1.4 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt-core/org.eclipse.cdt.core.macosx/src/org/eclipse/cdt/internal/core/macosx/ProcessList.java?root=Tools_Project&r1=1.3&r2=1.4
Looks good
