LLVM Bugzilla is read-only and represents the historical archive of all LLVM issues filled before November 26, 2021. Use github to submit LLVM bugs

Bug 24589 - Target is keeping an open handle to executable during test runs
Summary: Target is keeping an open handle to executable during test runs
Status: NEW
Alias: None
Product: lldb
Classification: Unclassified
Component: All Bugs (show other bugs)
Version: unspecified
Hardware: PC Windows NT
: P normal
Assignee: LLDB commit list
URL:
Keywords:
Depends on:
Blocks: 21766
  Show dependency tree
 
Reported: 2015-08-26 13:17 PDT by Zachary Turner
Modified: 2015-08-26 13:17 PDT (History)
1 user (show)

See Also:
Fixed By Commit(s):


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Zachary Turner 2015-08-26 13:17:52 PDT
When running many test cases in the test suite, all operations happen within a single process.  Most test suites simply clean and rebuild the entire executable with each test case which is currently necessary because a small number of tests (the exact set of which nobody is quite sure of) require this, and it is also necessary when switching between dsym and dwarf tests.

http://lists.llvm.org/pipermail/lldb-dev/2015-August/008073.html

On Windows, you can't delete the executable of a process that someone is holding a handle to, and due to some kind of bug in Target, a handle is sometimes behind held onto for reasons unknown.

This prevents all test cases after the first one to fail on the make clean step.

For now, a very hackish workaround has been implemented which will cause -- on Windows only -- Makefile.rules to use the builtin 'del' command instead of the 'rm' command that comes with GnuWin32.  'del' uses some kind of unknown technique to delete the file anyway, and this seems to have no other side effects.

Ultimately we need to fix

a) The test runner, so that it doesn't rebuild executables many times unnecessarily

and

b) LLDB, so that it properly frees process handles when it's done with them.

But this is an ok workaround for now, as long as we have this bug filed tracking the issue.