bug#60996: 29.0.60; Native compile fails to remove temp file for trampoline

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sat, 21 Jan 2023 22:12:10 +0000
> From: Andy Moreton <andrewjmoreton@gmail.com>
> 
> Recently emacs 29 (and master) has started showing an error and
> backtrace during startup:
> 
> Debugger entered--Lisp error: (permission-denied "Removing old name" 
> "Permission denied" "c:/Users/ajm/AppData/Local/Temp/comp-lambda-MTAMbr...")
> delete-file("c:/Users/ajm/AppData/Local/Temp/comp-lambda-MTAMbr...")

We need a reproducible recipe to investigate this, or results of such
investigation by you: which code has the file open when we try
deleting it, and why that other code has it open?

For a recipe, it should be enough to present a minimal init file which
causes the problem (but pleased make it really minimal: as few lines
as strictly needed for reproduction)

Btw, "comp-lambda-MTAMbr..." seems to tell that it's some part of
comp.el, which sounds strange: comp.el is supposed to be
natively-compiled during the build, and that includes the trampolines
for it.  Hmm...

> Tracing execution of emacs with Process Explorer shows that the temp
> file used to native compile trampolines is opened and closed repeatedly
> by emacs, and at the point of the backtrace is still open by the same
> emacs process.

We need to know which code opened it the last time and didn't close
it.  Can you figure that out?  All the files Emacs opens go through 2
functions in w32.c: sys_fopen and sys_open, so by running with 2
breakpoints there that show the backtrace and continue, you should be
able to see the culprit, and we can then take it from there.

> I am not sure excactly when this issue started, but I did not see it in
> emacs-29 or master bootstrapped before this month.

Could be because we now compile trampolines differently (to avoid the
danger of the "fork bomb" due to recursive compilation of
trampolines by async subprocesses).

Andrea, any suggestions or comments?

Thanks.