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

[Andy Moreton <andrewjmoreton@gmail.com>]

On Sun 22 Jan 2023, Eli Zaretskii wrote:

>> 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)

It may take considerable time and effort to reduce my init file down to a
simple reproducer...

> 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...

The backtrace always seems to contain:

  delete file("path/to/comp-lambda-XXXXX.eln")
  comp--native-compile((lambda (...) ...))
  comp-trampoline-compile(function-name)
  comp-subr-trampoline-install(function-name)
  advice--add-function(...)
  advice-add(function-name ...)

So it looks very much like compiling trampolines is involved.
  
>> 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.

Thanks. I'll take a look in gdb and report back if I get further info.

>> 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.