Bug 2112672

Summary: glibc: fwrite never returns an error when line buffering is used, SIGPIPE is ignored, and writes are returning EPIPE
Product: Red Hat Enterprise Linux 9 Reporter: Andrew Schorr <ajschorr>
Component: glibcAssignee: glibc team <glibc-bugzilla>
Status: CLOSED UPSTREAM QA Contact: qe-baseos-tools-bugs
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: CentOS StreamCC: ashankar, bstinson, codonell, dj, fweimer, jwboyer, mnewsome, pfrankli, sipoyare
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2022-08-08 17:39:05 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
simple C program to ignore SIGPIPE, configure stdout buffering, and fwrite a string repeatedly none

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.