Community
Participate
Working Groups
I was poking around my hard drive and found a mess of .ee files in the normal tempfile location (under the user dir). these appear to be something related to debug and is creation or parsing of ee files. Looks like hter eis a leak in the clean up code. I had about 100 of them in there. Not too big but still a leak
Moving to PDE/API Tooling, which creates temp .ee files.
steps to reproduce: 1. create a new API baseline 2. kill eclipse using the process explorer (or the kill command from the command line) If you then check your temp folder it will have left over .ee files in it. The current state of the code sets the 'delete on exit' request for the temp file, but if the VM that created the temp file exits abnormally, it does not process the request.
there may be other ways to reproduce this as I don't kill many Eclipse instances (nor do they generally crash) and yet my machine has/had quite a number of ee files. Are these files create regardless of whether or not you have somethin gin your workspace? The other option is that running tests that start a workspace might be causing this. These are often killed in the process fo debugging etc. Generally speaking however, for the things I have been doing, the workspaces are empty...
I found that there are two places we create temp ee files. Jeff what is the name of the file(s)? Is it one of 'eeFile.ee' or 'eed.ee'?
Created attachment 111151 [details] one of the wayward ee files Here is one of the files. eed22542.ee. I have about 30 of them on my disk right now ranging in creation time over the past week or so.
interestingly, we already set the deleteOnExit flag for all eed*.ee temp files we make, and the flag was not being set for any of the eefile*.ee temp files. I fixed the missing flag-setting for the eefile*.ee by removing the method that creates them (as it is not used anywhere), though I have no idea (yet) why any eed*.ee files would slip through the cracks, other than non-normal termination of the VM. Also cleaned up other unused methods from our Util class. excerpt from the doc for deletOnExit: "Deletion will be attempted only for normal termination of the virtual machine, as defined by the Java Language Specification"
Jeff, are you still getting more and more left over .ee files? I still cannot reproduce other than killing Eclipse (or having it crash), and the only place we create temp .ee files is during API baseline creation...
marking as worksforme
Reopening, testing our FileManager (part of the fix for bug 279729) it happened that I shut down my target Eclipse 'normally' and there were a bunch of the temp EE files left behind. We could probably also manage them with the FileManager as a back-up in case the VM fails to clean them.
this is still happening, and needs to be fixed
Created attachment 164732 [details] proposed fix I found a couple of places where we were creating temp ee files without the deleteOnExit flag, so I added a new method to our Util class: createTempFile(prefix, postfix) which sets the deleteOnExit flag and adds the file to our file manager. I updated all occurrences of File.createTempFile(..) to Util.createTempFile(..)
marking as readme as note to not use File.createTempFile(..) but instead always use our delegate method Util.createTempFile(..)
applied patch to HEAD, please verify Olivier
Verified.
Reopening. Smoke testing 3.7M7, I went looking for something that was extracted to my profile temp folder - <root>\AppData\Local\Temp on win 7) - and found ~2200 temp ee files (1.6MB worth) in there.
testing this I found that the files are only left behind from improperly terminating Eclipse / target workspaces - for example killing the process or using the terminate button in the console view for a target workspace - since none of the hooks to remove the files will be called. I don't see anything more we can do here. Remarking as fixed
remarking verified.
