RE: Permission Denied error while killing Gmake on Windows

[Anuj Shroff]

Hello Eli

Please find a small snippet of process name from ProcessExplorer attached. It 
shows the compiler names and the process name. 

While experiment a bit more with this we found an interesting workaround which 
seems to have given some promising results.

We tweaked the gmake source code so that when we are deleting targets while 
handling fatal signals (like SIGINT or SIGTERM), if we encounter an error we 
sleep for 3 seconds and retry.

In our case we are getting the Permission Denied error while deleting the obj 
files. When we used this new gmake, it gave us good results and we are no 
longer seeing the "deleting files: Permission Denied" error. Also the corrupt 
obj files (due to the interrupt) are cleaned up properly.

We would like to know your opinion on this.

Thanks
Anuj

-----Original Message-----
From: Eli Zaretskii [mailto:address@hidden 
Sent: Thursday, February 25, 2016 11:53 AM
To: Anuj Shroff <address@hidden>
Cc: address@hidden; Eric DeCosta <address@hidden>; Troy Runkel <address@hidden>
Subject: Re: Permission Denied error while killing Gmake on Windows

> From: Anuj Shroff <address@hidden>
> Date: Wed, 24 Feb 2016 21:11:02 +0000
> Cc: Eric DeCosta <address@hidden>,
>       Troy Runkel <address@hidden>
> 
> Our aim is to kill the gmake process along with its sub gmakes (child 
> processes) on windows and clean up properly (which involves unlinking object 
> files).
> 
> For this we created a script which would send a ‘CTRL + C’ event to 
> the main gmake process using win32::API of Perl. When we monitor the 
> progress, the main gmake and child gmakes are killed properly. We see 
> that the correct signal is being propagated to the gmake process. However, 
> the cleanup is not happening as expected. When it tries to unlink all these 
> “obj” files, it gives a Permission denied error.
> 
> To understand more about it we read the source code. We found that 
> while handling 'CTRL + C' signal gmake suspends its main thread. While 
> the main thread is suspended, it tries to kill the child processes and 
> clean up the files. While the files (mainly obj files) are being 
> cleaned up (unlinked) we get the Permission denied issue as the file seems to 
> have a lock on it. We suspect that this lock is detected by the filer that 
> the file is still in use by the compiler which is the main thread.

The compiler is a separate program, so it shouldn't matter whether the cleanup 
is done from the main thread of gmake or from another thread.
If the compiler has the file open, deleting it will fail, and there's nothing 
gmake can do about that.  However, the files are cleaned up after the compiler 
is killed, so the file should not be open anymore.
So I'm unsure why you see these problems

What compiler are you running under gmake?

> Hence, it gives a Permission Denied error. As the file is on the 
> network filer this issue is much more prominent. However, when these 
> files are created on the local drive these issues are much less visible (Not 
> completely gone but less).

I never saw such problems in local drives.  Never.

Compilers_gmake.png
Description: Compilers_gmake.png