target delete doesn't drop file handles

I’ve tracked down the source of a bunch of test failures on Windows which are caused by file handle leaks. The symptom of the problem is that if you run “file a.out” the file is locked after that, and you cannot delete it. This causes a bunch of tests to fail when “make clean” can’t delete the file.

Thas to do with the nature of the Windows kernel and how it treats memory mapped files. Essentially what is happening is that ModuleList::GetSharedModule() is mmapping the file and intentionally leaking the handle. So even doing target delete won’t free the handle.

I’m guessing this is an optimization, but how necessary is it? Assuming it needs to stay, would it be reasonable for me to disable this intentional leak for Windows behind a preprocessor definition, make target delete remove the module from the shared module list, and update the test suite to always free created targets on teardown?

It looks like target delete has a --clean option which does what I need. So I think that means the answer to my question of whether or not it’s important is yes, and so I’ll probably just want to change the default value from false to true on Windows. Is there any precedent for having command options take different default values on different platforms?

I wouldn't do that. If you re-run your target you don't want to have to load all of your shared libraries agains from scratch and re-parse all debug info.

I would guess you should fix the test suite to run some extra commands to cleanup each target after each test so the target itself can go away.

Please don't change mmap stuff on unix, it is fine to disable this on Windows, but again, you will want to debug a large target and make sure you aren't regressing on performance as you will be reading and entire file into memory regardless of the pages you touch, so I would recommend leaving the mmap stuff in and enabled and just fix the test suite to clean targets when it is done.

Greg Clayton