[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 11:49:33 +0300

On Fri, Jun 16, 2017 at 9:23 AM, Eli Zaretskii <address@hidden> wrote:
> From: Orgad Shaneh <address@hidden>
> Date: Fri, 16 Jun 2017 00:46:34 +0300
> Ok, I found out that the bug is not (entirely) in make. What causes this problem is the following patch applied
> by MSYS2 packages of mingw make:
> diff -Naur make-4.2.1/main.c make-4.2.1.new/main.c
> --- make-4.2.1/main.c 2016-05-31 09:17:26.000000000 +0200
> +++ make-4.2.1.new/main.c 2017-02-20 22:55:09.051617838 +0100
> @@ -1126,8 +1126,11 @@
> #endif
> +/* setlocale interferes with line buffering if using parallel make on MinGW */
> +#ifndef __MINGW32__
> /* Set up gettext/internationalization support. */
> setlocale (LC_ALL, "");
> +#endif
> /* The cast to void shuts up compiler warnings on systems that
> disable NLS. */
> (void)bindtextdomain (PACKAGE, LOCALEDIR);

I'd certainly like to know why "setlocale interferes with line
buffering if using parallel make on MinGW".  Could you perhaps ask the
MSYS2 maintainers to report their findings here or on make-w32?


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

On Fri, Jun 16, 2017 at 9:29 AM, Eli Zaretskii <address@hidden> wrote:
> From: Orgad Shaneh <address@hidden>
> Date: Fri, 16 Jun 2017 01:16:09 +0300
> ... or not. I still get it even without this patch, when running from IDE. Reverting the patch only fixes the issue
> when running in command line.
> I did file a bug[1], but this is not the real reason. Probably timing issue.

Most probably.  It also could be indirectly caused by your recipes.

Unlikely. I reduced it to the most minimal recipe (build a single c++ file), and it still happens 

> Another thing I've noticed is that make (on Windows/MinGW) leaves behind suspended processes when it is
> aborted. Maybe one of these processes holds the file and prevents it from being deleted?

Could be, you should be able to use Process Explorer to see who holds
a handle on the files that fail to be deleted.

The handle is released immediately after make is done.
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

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 think g++ is the most common use-case for make, so this must be handled properly.

> If you can suggest ways to debug and fix this problem, I'll be thankful.

Well, I'd start by posting a minimal Makefile and auxiliary files that
allow to reproduce the issue.

I'll try to create one later.

Another approach would be to try the MinGW build here:


where you can also find Make built with Guile support, something I
don't think MSYS2 guys offer.

It's the same. 

- Orgad

Attachment: unlink.csv
Description: Text Data

reply via email to

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