Re: [bug #60774] make hangs on fcntl lock when using -O and stdout is /dev/null

[Dmitry Goncharov via Bug reports and discussion for GNU make]

Wanted to test that windows this still works with this change.

So, i followed instructions in README.W32.
Installed mingw gcc. Copied config.h.W32.template to config.h.w32.
Ran build_W32.bat gcc. It fails with

C:\dgoncharov\make>gcc -mthreads -Wall -std=gnu99 -gdwarf-2 -g3 -O2 -DMAKE_MAINT
AINER_MODE -I.\GccRel/src -I./src -I.\GccRel/lib -I./lib -I./src/w32/include -DW
INDOWS32 -DHAVE_CONFIG_H  -o .\GccRel/src/ar.o -c src/ar.c
In file included from src/ar.c:18:
src/makeint.h:314:13: error: conflicting types for 'mode_t'
 typedef int mode_t;
 ^~
In file included from src/makeint.h:86,
 from src/ar.c:18:
c:/Program Files (x86)/mingw-w64/i686-8.1.0-posix-dwarf-rt_v6-rev0/mingw32/i686-
w64-mingw32/include/sys/types.h:77:17: note: previous declaration of 'mode_t' wa
s here  typedef _mode_t mode_t;

Both make and mingw declare mode_t.
More errors like this follow.

Does anyone have a ready to use config.h.W32?


regards, Dmitry

[bug #60774] make hangs on fcntl lock when using -O and stdout is /dev/null

[Dmitry Goncharov]

Follow-up Comment #7, bug #60774 (project make):

The windows code, which passes down the semaphore to children is reused to
pass down the fd on unix.

> The way you propose to reuse the Windows code brings that Windows-specific
stuff back into view.

it is not clear to me what windows specific stuff you mean.
Let us go over it?

record_sync_mutex reads the value of the fd from the env variable. Reused
between unix and windows.

prepare_mutex_handle_string stores the value of the fd in makeflags. Reused
between unix and windows.

create_mutex is modified to return the value of the semaphore. Still windows
specific.

mutex_handle - global variable. Removed. Instead of mutex_handle and
sync_handle, there is only sync_handle.



___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

Re: [bug #60774] make hangs on fcntl lock when using -O and stdout is /dev/null

[Dmitry Goncharov via Bug reports and discussion for GNU make]

On Sat, Jul 24, 2021 at 3:02 PM David Boyce  wrote:

> The point is that only /dev/null *should* be shared. Any other file *might* 
> be locked by an unrelated process but that would represent an error condition 
> in which incorrect results should be expected.

i think, it is less likely that an unrelated process locks a make's
private temp file, than a system wide global file.

> I can’t think of a file other than /dev/null which would appropriately be 
> shared with unrelated processes in a “w” (write) condition.

/dev/zero, /dev/lp0, /dev/lp1, /dev/pts, etc.
i recognize the simplicity of using stdout. However, i also dislike
adding pieces of code for a set of special files. The user will always
find a way to screw it.

Also, make is portable. What about those systems which do not have
inode/devices?

regards, Dmitry

Re: [bug #60774] make hangs on fcntl lock when using -O and stdout is /dev/null

[David Boyce]

> That would help this specific case indeed...

The point is that only /dev/null *should* be shared. Any other file *might* be 
locked by an unrelated process but that would represent an error condition in 
which incorrect results should be expected. I can’t think of a file other than 
/dev/null which would appropriately be shared with unrelated processes in a “w” 
(write) condition. 

> On Jul 24, 2021, at 2:15 PM, Dmitry Goncharov  wrote:
> 
> That would help this specific case indeed.

[bug #60774] make hangs on fcntl lock when using -O and stdout is /dev/null

[Eli Zaretskii]

Follow-up Comment #6, bug #60774 (project make):

The idea of keeping the Windows code separate was to avoid cluttering common
sources with Windows-specific stuff.  The way you propose to reuse the Windows
code brings that Windows-specific stuff back into view.

But if Paul doesn't mind, neither do I.


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

Re: [bug #60774] make hangs on fcntl lock when using -O and stdout is /dev/null

[Dmitry Goncharov via Bug reports and discussion for GNU make]

On Saturday, July 24, 2021, David Boyce  wrote:

> Wouldn’t a less intrusive solution be to check the inode/device of stdout
> and if it’s the same as that of /dev/null just forego locking?


That would help this specific case indeed.
What about a case when make's stdout is redirected to another, not dev
null, file? Any file could be locked.

Another case is when a child's stdout is redirected to a file different
from parent.

Regards, Dmitry

>
> > On Jul 24, 2021, at 11:26 AM, Eli Zaretskii 
> wrote:
> >
> > Follow-up Comment #5, bug #60774 (project make):
> >
> > The MS-Windows port of GNU Make doesn't lock stdout (or any other
> standard
> > device).  Instead, it uses a mutex to synchronize output.  So I think
> this
> > problem cannot happen on Windows.
> >
> > But I see that your changeset touches quite a few places in the code
> which is
> > Windows specific, and I wonder why did you have to do that, since the
> problem
> > you are trying to fix doesn't exist there.  Wouldn't it be more prudent
> to
> > leave the Windows-only code alone?
> >
> >
> >___
> >
> > Reply to this item at:
> >
> >  
> >
> > ___
> >  Message sent via Savannah
> >  https://savannah.gnu.org/
> >
> >
>

Re: [bug #60774] make hangs on fcntl lock when using -O and stdout is /dev/null

[Dmitry Goncharov via Bug reports and discussion for GNU make]

On Saturday, July 24, 2021, Eli Zaretskii  wrote:

> Follow-up Comment #5, bug #60774 (project make):
>
> The MS-Windows port of GNU Make doesn't lock stdout (or any other standard
> device).  Instead, it uses a mutex to synchronize output.  So I think this
> problem cannot happen on Windows.


True.

>
> But I see that your changeset touches quite a few places in the code which
> is
> Windows specific, and I wonder why did you have to do that, since the
> problem
> you are trying to fix doesn't exist there.  Wouldn't it be more prudent to
> leave the Windows-only code alone?


The windows code, which passes down the semaphore to children is reused to
pass down the fd on unix. If we leave it alone, we'd have to duplicate the
mechanism on unix.


Regards, Dmitry

> ___
>
> Reply to this item at:
>
>   
>
> ___
>   Message sent via Savannah
>   https://savannah.gnu.org/
>
>

Re: [bug #60774] make hangs on fcntl lock when using -O and stdout is /dev/null

[David Boyce]

Wouldn’t a less intrusive solution be to check the inode/device of stdout and 
if it’s the same as that of /dev/null just forego locking?

> On Jul 24, 2021, at 11:26 AM, Eli Zaretskii  wrote:
> 
> Follow-up Comment #5, bug #60774 (project make):
> 
> The MS-Windows port of GNU Make doesn't lock stdout (or any other standard
> device).  Instead, it uses a mutex to synchronize output.  So I think this
> problem cannot happen on Windows.
> 
> But I see that your changeset touches quite a few places in the code which is
> Windows specific, and I wonder why did you have to do that, since the problem
> you are trying to fix doesn't exist there.  Wouldn't it be more prudent to
> leave the Windows-only code alone?
> 
> 
>___
> 
> Reply to this item at:
> 
>  
> 
> ___
>  Message sent via Savannah
>  https://savannah.gnu.org/
> 
> 

[bug #60774] make hangs on fcntl lock when using -O and stdout is /dev/null

[Eli Zaretskii]

Follow-up Comment #5, bug #60774 (project make):

The MS-Windows port of GNU Make doesn't lock stdout (or any other standard
device).  Instead, it uses a mutex to synchronize output.  So I think this
problem cannot happen on Windows.

But I see that your changeset touches quite a few places in the code which is
Windows specific, and I wonder why did you have to do that, since the problem
you are trying to fix doesn't exist there.  Wouldn't it be more prudent to
leave the Windows-only code alone?


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #60774] make hangs on fcntl lock when using -O and stdout is /dev/null

[Dmitry Goncharov]

Follow-up Comment #4, bug #60774 (project make):

In your case, Mike, you can either try this fix or find the offending process
with lsof and kill it.

___

Reply to this item at:

  

___
  Сообщение отправлено по Savannah
  https://savannah.gnu.org/

[bug #60774] make hangs on fcntl lock when using -O and stdout is /dev/null

[Dmitry Goncharov]

Follow-up Comment #3, bug #60774 (project make):

i pushed a fix here
https://github.com/dgoncharov/make/tree/sv_60774_output_sync_deadlock.
This fix does the following.

Lock a temp file to synchronize output.

1. Lock a temp file, rather than stdout, to synchronize output.
Locking stdout prevents make from obtaining the lock when another process has
make's stdout locked. E.g make's stdout is redirected to /dev/null and another
process has /dev/null locked.

2. Pass the file descriptor of this lock file to children through env in
MAKEFLAGS' sync-mutex.

3. Check that a file can be locked before locking it.  With a temp file this
check in acquire_semaphore is not supposed to fail. It won't hurt though.

4. Print a warning message when cannot synchronize output.

Tested this fix on linux. Will be good if anybody could test this fix on
windows.

___

Reply to this item at:

  

___
  Сообщение отправлено по Savannah
  https://savannah.gnu.org/

[bug #60774] make hangs on fcntl lock when using -O and stdout is /dev/null

[Dmitry Goncharov]

Follow-up Comment #2, bug #60774 (project make):

Thanks for your report, Mike.

make uses file locking on stdout to synchronize output.

int fd = fileno(STDOUT);
fcntl (fd, F_SETLKW, );

After fcntl return make prints its output.

In your case another process has /dev/null locked. With make's stdout
redirected to /dev/null, make blocks in this call to fcntl.

___

Reply to this item at:

  

___
  Сообщение отправлено по Savannah
  https://savannah.gnu.org/