[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Unlink failure on abort

From: Orgad Shaneh
Subject: Re: Unlink failure on abort
Date: Fri, 16 Jun 2017 15:59:09 +0300

On Fri, Jun 16, 2017 at 3:52 PM, Eli Zaretskii <address@hidden> wrote:
> From: Orgad Shaneh <address@hidden>
> Date: Fri, 16 Jun 2017 11:49:33 +0300
> Cc: address@hidden
>  In general, killing subprocesses is problematic on Windows, because
>  only child processes can be killed, the grandchildren cannot.
>  Therefore, rearranging your build commands might make the issue go
>  away.
> Then this can explain the problem. g++.exe invokes a child process cc1plus.exe. Maybe g++ is killed, but
> cc1plus still has the file open. Then both g++ and make try to unlink the file, but they both fail. I attach a
> Process Monitor log for this scenario.

I don't see any calls to DeleteFile in this log.  I expected to see at
least one that failed with ERROR_ACCESS_DENIED.  What am I missing?

There is SHARING_VIOLATION for both g++.exe and mingw32-make.exe

>> I'm not sure, but you can see in my bug report that the output is interleaved without this patch.

> Interleaved output is not a problem, it's expected behavior.  And it
> has nothing to do with buffering, since several different instances of
> make are simultaneously writing to the same device.

By "interleaved" I mean that in the same line there is "expected" output and interferences. This happens even without -j. In the example that I gave in that bug report, it was caused by ^C, which looked like this:

make: *** Deleting file 'obj/m^ainC.oTerminate batch job (Y/N)? '
Is this expected? With the patch it doesn't happen.

- Orgad

reply via email to

[Prev in Thread] Current Thread [Next in Thread]