Bug 2112672 - glibc: fwrite never returns an error when line buffering is used, SIGPIPE is ignored, and writes are returning EPIPE
Summary: glibc: fwrite never returns an error when line buffering is used, SIGPIPE is ...
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Red Hat Enterprise Linux 9
Classification: Red Hat
Component: glibc
Version: CentOS Stream
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: glibc team
QA Contact: qe-baseos-tools-bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2022-07-31 14:42 UTC by Andrew Schorr
Modified: 2023-07-18 14:29 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-08-08 17:39:05 UTC
Type: Bug
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
simple C program to ignore SIGPIPE, configure stdout buffering, and fwrite a string repeatedly (1.19 KB, text/x-csrc)
2022-07-31 14:42 UTC, Andrew Schorr
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker RHELPLAN-129728 0 None None None 2022-07-31 14:58:33 UTC
Sourceware 29459 0 P2 NEW fwrite does not return EPIPE when underlying write fails with EPIPE. 2022-08-08 17:37:13 UTC

Description Andrew Schorr 2022-07-31 14:42:09 UTC
Created attachment 1900380 [details]
simple C program to ignore SIGPIPE, configure stdout buffering, and fwrite a string repeatedly

Description of problem: With line buffering configured on stdout,
and SIGPIPE ignored, fwrite calls to stdout on a broken pipe never report
an error.


Version-Release number of selected component (if applicable):
glibc-2.34-39.el9.x86_64


How reproducible:
always

Steps to Reproduce:
1. Compile and run the attached program fwrite.c
2. fwrite -l hello 5000 | head -n1
3.

Actual results:
The program succeeds in calling fwrite 5000 times to print hello,
even though the writes are actually failing with EPIPE.

Expected results:
The fwrite call should return an error. At some point, ferror starts
returning 1, but fwrite continues to succeed.


Additional info:

Comment 1 Andrew Schorr 2022-07-31 14:44:00 UTC
FYI, this problem is an old one. I see this issue in CentOS 7.9 as well. I haven't tried 8.

Comment 2 Carlos O'Donell 2022-08-08 17:39:05 UTC
I've submitted this upstream to the upstream bug tracker since this behaviour needs to fixed upstream.

When we get a fix upstream then we can consider backporting this into CentOS Stream and RHEL.

I'm going to mark this a CLOSED/USPTREAM and track the bug upstream, we can reopen this for backport when the usptream work is complete.


Note You need to log in before you can comment on or make changes to this bug.