Re: Unlink failure on abort

On Sun, 2017-12-03 at 17:39 +0200, Orgad Shaneh wrote: > On Fri, Jun 23, 2017 at 2:59 AM, Paul Smith wrote: > > On Tue, 2017-06-20 at 18:20 +0300, Eli Zaretskii wrote: > > > > Date: Sun, 18 Jun 2017 17:42:51 +0300 > > > > From: Eli Zaretskii > > > > Cc:

Re: Unlink failure on abort

On Fri, Jun 23, 2017 at 2:59 AM, Paul Smith wrote: > > On Tue, 2017-06-20 at 18:20 +0300, Eli Zaretskii wrote: > > > Date: Sun, 18 Jun 2017 17:42:51 +0300 > > > From: Eli Zaretskii > > > Cc: alex...@gmail.com, bug-make@gnu.org > > > > I think the problem is that

Re: Unlink failure on abort

On Tue, 2017-06-20 at 18:20 +0300, Eli Zaretskii wrote: > > Date: Sun, 18 Jun 2017 17:42:51 +0300 > > From: Eli Zaretskii > > Cc: alex...@gmail.com, bug-make@gnu.org > > > I think the problem is that reap_children() is called after > > > delete_child_targets, so the child jobs can

Re: Unlink failure on abort

> Date: Sun, 18 Jun 2017 17:42:51 +0300 > From: Eli Zaretskii > Cc: alex...@gmail.com, bug-make@gnu.org > > > I think the problem is that reap_children() is called after > > delete_child_targets, so the child jobs can still run > > while make is trying to delete. > > > > Maybe

Re: Unlink failure on abort

On Sun, Jun 18, 2017 at 6:13 PM, Eli Zaretskii wrote: > > From: Orgad Shaneh > > Date: Sun, 18 Jun 2017 17:50:56 +0300 > > Cc: bug-make@gnu.org, Alexey Pavlov > > > > > I used Sleep(5), and had count of 2 (I had the same with Sleep(50)). > >

Re: Unlink failure on abort

> From: Orgad Shaneh > Date: Sun, 18 Jun 2017 17:50:56 +0300 > Cc: bug-make@gnu.org, Alexey Pavlov > > > I used Sleep(5), and had count of 2 (I had the same with Sleep(50)). > > That's strange. How many cores do you have on that system? > > 4 So that

Re: Unlink failure on abort

> From: David Boyce > Date: Sun, 18 Jun 2017 04:42:43 -0700 > Cc: Eli Zaretskii , Alexey Pavlov , bug-make > > > In the event this patch is used: I think the interleaved-ifdef style is hard > to read and best avoided.

Re: Unlink failure on abort

On Sun, Jun 18, 2017 at 2:42 PM, David Boyce wrote: > In the event this patch is used: I think the interleaved-ifdef style is > hard to read and best avoided. How about either separating the Windows and > "other" clauses at the top level or something like this (with

Re: Unlink failure on abort

On Sun, Jun 18, 2017 at 5:42 PM, Eli Zaretskii wrote: > > From: Orgad Shaneh > > Date: Sun, 18 Jun 2017 08:02:21 +0300 > > Cc: bug-make@gnu.org, Alexey Pavlov > > > > Please try the same, but with Sleep calls using 10 or even 5 msec (and > >

Re: Unlink failure on abort

> From: Orgad Shaneh > Date: Sun, 18 Jun 2017 08:02:21 +0300 > Cc: bug-make@gnu.org, Alexey Pavlov > > Please try the same, but with Sleep calls using 10 or even 5 msec (and > enlarging the loop count if necessary). I'd be interested to see the >

Re: Unlink failure on abort

In the event this patch is used: I think the interleaved-ifdef style is hard to read and best avoided. How about either separating the Windows and "other" clauses at the top level or something like this (with suitable comment): + for (e = 0; e < 10; ++e) +{ + status = unlink

Re: Unlink failure on abort

On Sun, Jun 18, 2017 at 5:31 AM, Eli Zaretskii wrote: > > From: Orgad Shaneh > > Date: Sat, 17 Jun 2017 23:04:11 +0300 > > Cc: bug-make@gnu.org, Alexey Pavlov > > > > +#ifdef WINDOWS32 > > + for (e = 0; e < 10; ++e) > > +{ > >

Re: Unlink failure on abort

> From: Orgad Shaneh > Date: Sat, 17 Jun 2017 23:04:11 +0300 > Cc: bug-make@gnu.org, Alexey Pavlov > > +#ifdef WINDOWS32 > + for (e = 0; e < 10; ++e) > +{ > +#endif > + status = unlink (file->name); > +#ifdef WINDOWS32 > + if

Re: Unlink failure on abort

> From: Orgad Shaneh > Date: Fri, 16 Jun 2017 17:05:58 +0300 > Cc: "bug-make@gnu.org" , Alexey Pavlov > > Ah, okay. But then the problem is not with child processes of g++, > it's with g++ itself, right? > > The child process cc1plus has

Re: Unlink failure on abort

On Friday, June 16, 2017, Eli Zaretskii wrote: > > From: Orgad Shaneh > > > Date: Fri, 16 Jun 2017 15:59:09 +0300 > > Cc: bug-make@gnu.org > > > > I don't see any calls to DeleteFile in this log. I expected to see at > > least one

Unlink failure on abort

On Friday, June 16, 2017, Eli Zaretskii > wrote: > > Date: Fri, 16 Jun 2017 16:15:31 +0300 > > From: Eli Zaretskii > > Cc: bug-make@gnu.org > > > > > Ok, I was able to create a minimal example. It happens only with g++ >

Re: Unlink failure on abort

> From: Orgad Shaneh > Date: Fri, 16 Jun 2017 15:59:09 +0300 > Cc: bug-make@gnu.org > > 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

Re: Unlink failure on abort

> Date: Fri, 16 Jun 2017 16:15:31 +0300 > From: Eli Zaretskii > Cc: bug-make@gnu.org > > > Ok, I was able to create a minimal example. It happens only with g++ -pipe. > > Thanks, but I couldn't reproduce the problem on my main development > machine. Correction: I do succeed

Re: Unlink failure on abort

> From: Orgad Shaneh > Date: Fri, 16 Jun 2017 14:24:13 +0300 > Cc: bug-make@gnu.org > > Ok, I was able to create a minimal example. It happens only with g++ -pipe. Thanks, but I couldn't reproduce the problem on my main development machine. In my case, Make succeeds to delete

Re: Unlink failure on abort

On Fri, Jun 16, 2017 at 3:52 PM, Eli Zaretskii wrote: > > From: Orgad Shaneh > > Date: Fri, 16 Jun 2017 11:49:33 +0300 > > Cc: bug-make@gnu.org > > > > In general, killing subprocesses is problematic on Windows, because > > only child processes can be killed,

Re: Unlink failure on abort

> From: Orgad Shaneh > Date: Fri, 16 Jun 2017 11:49:33 +0300 > Cc: bug-make@gnu.org > > 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

Re: Unlink failure on abort

> From: Orgad Shaneh > Date: Fri, 16 Jun 2017 11:49:33 +0300 > Cc: bug-make@gnu.org > > 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

Re: Unlink failure on abort

On Fri, Jun 16, 2017 at 11:49 AM, Orgad Shaneh wrote: > On Fri, Jun 16, 2017 at 9:23 AM, Eli Zaretskii wrote: > >> > From: Orgad Shaneh >> > Date: Fri, 16 Jun 2017 00:46:34 +0300 >> > >> > Ok, I found out that the bug is not (entirely) in make.

Re: Unlink failure on abort

On Fri, Jun 16, 2017 at 9:06 AM, Eli Zaretskii wrote: > > From: Orgad Shaneh > > Date: Thu, 15 Jun 2017 22:33:30 +0300 > > > > When I abort a build, make fails to unlink the intermediate files. I > previously used 4.1.90, and I don't remember > > having these

Re: Unlink failure on abort

On Fri, Jun 16, 2017 at 9:23 AM, Eli Zaretskii wrote: > > From: Orgad Shaneh > > 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

Re: Unlink failure on abort

On Fri, 16 Jun 2017 01:16:09 +0300 Orgad Shaneh wrote: > > On Thu, Jun 15, 2017 at 10:33 PM, Orgad Shaneh > > wrote: > >> mingw32-make[1]: *** Deleting file 'obj/main.o' > >> mingw32-make[1]: unlink: obj/main.o: Permission denied > Another thing I've noticed

Re: Unlink failure on abort

> From: Orgad Shaneh > 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.

Re: Unlink failure on abort

> From: Orgad Shaneh > 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 > ---

Re: Unlink failure on abort

> From: Orgad Shaneh > Date: Thu, 15 Jun 2017 22:33:30 +0300 > > When I abort a build, make fails to unlink the intermediate files. I > previously used 4.1.90, and I don't remember > having these problems. > > This happens even for a single job (without -j). > > Output: >

Re: Unlink failure on abort

On Friday, June 16, 2017, Henrik Carlqvist wrote: > On Fri, 16 Jun 2017 01:16:09 +0300 > Orgad Shaneh > wrote: > > > > On Thu, Jun 15, 2017 at 10:33 PM, Orgad Shaneh > > > > wrote: > > >> mingw32-make[1]: ***

Re: Unlink failure on abort

On Fri, Jun 16, 2017 at 12:46 AM, Orgad Shaneh wrote: > On Thu, Jun 15, 2017 at 10:33 PM, Orgad Shaneh wrote: > >> Hi, >> >> I'm using mingw32-make 4.2.1 from MSYS2/mingw32. >> >> When I abort a build, make fails to unlink the intermediate files. I >>

Re: Unlink failure on abort

On Thu, Jun 15, 2017 at 10:33 PM, Orgad Shaneh wrote: > Hi, > > I'm using mingw32-make 4.2.1 from MSYS2/mingw32. > > When I abort a build, make fails to unlink the intermediate files. I > previously used 4.1.90, and I don't remember having these problems. > > This happens even

Unlink failure on abort

Hi, I'm using mingw32-make 4.2.1 from MSYS2/mingw32. When I abort a build, make fails to unlink the intermediate files. I previously used 4.1.90, and I don't remember having these problems. This happens even for a single job (without -j). Output: main.cpp mingw32-make[1]: *** Deleting file