[bug #62840] make --version in pipe return SIGPIPE

[Paul D. Smith]

Update of bug #62840 (project make):

  Status:None => Fixed  
 Open/Closed:Open => Closed 
   Fixed Release:None => SCM


___

Reply to this item at:

  

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

[bug #62840] make --version in pipe return SIGPIPE

[Paul D. Smith]

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

Thanks for that patch.  After looking at it I added some more cleanup.

I saw one weird thing: we allow the --version option to be accepted from the
environment:


$ MAKEFLAGS=--version make
GNU Make 4.3
  ...


and doesn't try to build any targets.  I don't think this is a good idea. 
Anyone have a good reason to keep this behavior?


___

Reply to this item at:

  

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

[bug #62840] make --version in pipe return SIGPIPE

[Dmitry Goncharov]

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

Patch sv62840_fix.diff sets stdout to line buffering after --version and
--help are processed, but before make reads makefiles.


___

Reply to this item at:

  

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

[bug #62840] make --version in pipe return SIGPIPE

[Dmitry Goncharov]

Additional Item Attachment, bug #62840 (project make):

File name: sv62840_fix.diff   Size:2 KB




___

Reply to this item at:

  

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

[bug #62840] make --version in pipe return SIGPIPE

[Paul D. Smith]

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

The reason GNU make behaves differently here is that for a normal program when
you pipe its output the system automatically sets the stdout stream to block
buffered mode (the default is line buffered mode).

This means that the entire version string is buffered in the stream, then it
will be written as a single block when you flush (or exit, or the block fills
up: but blocks are usually 1K or more so that won't happen for version info
output).  Because it goes as a single block, the entire thing will be written
to the pipe before the reader closes the pipe.

However, due to GNU make's output sync feature, make will force stdout to be
in line buffered mode (where each line is flushed as its written) at all
times.  This means that GNU make is writing its output in multiple separate
system calls, which means it might get a write failure if the reader closes
the pipe early.

Unfortunately I'm not sure there's a simple way to avoid this.  I'll have to
think about it.


___

Reply to this item at:

  

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

Re: [bug #62840] make --version in pipe return SIGPIPE

[Henrik Carlqvist]

On Sat, 30 Jul 2022 13:26:46 -0400 (EDT)
Martin Dorey  wrote:
> Follow-up Comment #2, bug #62840 (project make):
> 
> Just for completeness or academic interest, then, this makes it happen
> reliably for me:
> 
> 
> set -o pipefail; { ruby -we '$stdout.write("x" * 4096)'; make --version; } |
> head -n1; echo $?

It was not a reliable way to reproduce the "bug" here:

-8<---
bash-4.3$ set -o pipefail; { ruby -we '$stdout.write("x" * 4096)'; make
--version; } | head -n1; echo $?
  
...
GNU Make 4.1
0
-8<---

But I would agree that it is not a bug. A program writing to a pipe is
expected to get a SIGPIPE and possibly return an error code if the pipe closes
before the program is finished.

However, the program is not guaranteed to get a SIGPIPE, there are also
buffers which the program might be able to write to even though those buffers
might not be emptied by the receiving process.

regards Henrik

[bug #62840] make --version in pipe return SIGPIPE

[Martin Dorey]

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

Just for completeness or academic interest, then, this makes it happen
reliably for me:


set -o pipefail; { ruby -we '$stdout.write("x" * 4096)'; make --version; } |
head -n1; echo $?


That behaved the same all the way back to make-3.81.  This was the first
command I found that behaved like make --version:


set -o pipefail; { ruby -we '$stdout.write("x" * 4096)'; tar --help; } | head
-n1; echo $?



___

Reply to this item at:

  

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

[bug #62840] make --version in pipe return SIGPIPE

[Paul D. Smith]

Follow-up Comment #1, bug #62840 (project make):

I'm not convinced that this is a bug.  First, it's highly timing-dependent:
when I tried it it didn't fail:


$ make --version | head -n1
GNU Make 4.3

$ echo $?
0


Second, you can get similar behavior from other commands; you just have to be
sure that the writer is still trying to write when the reader (head) has
exited.  For example:


$ (/bin/echo one; sleep 1; /bin/echo hi) | head -n1
one
/bin/echo: write error: Broken pipe

$ echo $?
1


Here /bin/echo exits with 1 not 141 but it's the same thing with a different
exit code.


___

Reply to this item at:

  

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

[bug #62840] make --version in pipe return SIGPIPE

[Tzvetelin Katchov]

URL:
  

 Summary: make --version in pipe return SIGPIPE
 Project: make
   Submitter: katchov
   Submitted: Sat 30 Jul 2022 04:24:33 PM UTC
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: 4.3
Operating System: POSIX-Based
   Fixed Release: None
   Triage Status: None


___

Follow-up Comments:


---
Date: Sat 30 Jul 2022 04:24:33 PM UTC By: Tzvetelin Katchov 
$ set -o pipefail
$ make --version | head -n1
GNU Make 4.3
$ echo $?
141








___

Reply to this item at:

  

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