Re: Unlink failure on abort

[Orgad Shaneh]

On Fri, Jun 16, 2017 at 11:49 AM, Orgad Shaneh <address@hidden> wrote:

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?

TIA

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

  https://sourceforge.net/projects/ezwinports/files/?source=navbar

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

It's the same. 

- Orgad

Ok, I was able to create a minimal example. It happens only with g++ -pipe.

fib.cpp (takes very long to compile):

#include <iostream>

template <int TreePos, int N>

struct FibSlow_t {

    enum { value = FibSlow_t<TreePos, N - 1>::value + 

            FibSlow_t<TreePos + (1 << N), N - 2>::value, };

};

template <int TreePos> struct FibSlow_t<TreePos, 1> {

    enum { value = 1 };

};

 

// Explicitly specialized for N==1

template <int TreePos> struct FibSlow_t<TreePos, 0> {

    enum { value = 0 };

};

using namespace std;

int main()

{

cout<<FibSlow_t<0, 70>::value<<endl;

}

-------

Makefile:

fib.o: fib.cpp

g++ -pipe -c -o fib.o fib.cpp

Run make fib.o, then Ctrl-C.

- Orgad