GNU bug report logs - #74788
Incorrect return value for SIGPIPE case

Previous Next

To reply to this bug, email your comments to 74788 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Sachin T <sachintu47 <at> gmail.com>
To: bug-grep <at> gnu.org
Subject: Incorrect return value for SIGPIPE case
Date: Wed, 11 Dec 2024 18:29:41 +0530

[Message part 1 (text/plain, inline)]

Hi Grep Team,

I am running version 3.11 of grep on the IBM z/OS platform.

I am testing a scenario where grep's output is redirected to a closed pipe.
This was expected to raise a SIGPIPE signal and return an exit status of
141.

Upon inspecting the code, I noticed that the signal is raised by fclose,
which is executed as part of the *clean_up_stdout* handler registered with
atexit. However, on the z/OS platform, when a signal is raised during the
execution of an atexit-registered function, the exit status of the program
is determined by the main program's return status rather than the signal's
exit code. In this case, the exit status is 0, which does not reflect the
SIGPIPE signal.

Could you suggest the preferred solution for handling this situation on the
z/OS platform? Additionally, would it be possible for this behavior to be
addressed as a bug fix specific to the z/OS platform in a future release?

Looking forward to your response.

Regards,
Sachin

[Message part 2 (text/html, inline)]

Message #8 received at 74788 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Sachin T <sachintu47 <at> gmail.com>
Cc: 74788 <at> debbugs.gnu.org
Subject: Re: bug#74788: Incorrect return value for SIGPIPE case
Date: Wed, 11 Dec 2024 09:54:47 -0800

On 2024-12-11 04:59, Sachin T wrote:
> Could you suggest the preferred solution for handling this situation on the
> z/OS platform?

Since this problem afflicts many applications (not just grep), the 
preferred solution would be to fix z/OS so that a process terminated by 
a signal has the exit status corresponding to the signal, even if the 
signal arrives during calls by 'exit' to functions registered by 
'atexit'. This is required by POSIX[1] and is what other systems do. Is 
that something you could start the ball rolling on? (I don't use z/OS 
and so cannot file bug reports for it.)

I don't see any straightforward change to 'grep' that would work around 
the z/OS problem. However, if you can think of a change, please let us know.

Also, could you please let us know the z/OS version so that I can 
document this portability problem in Gnulib? Thanks.

[1]: 
https://pubs.opengroup.org/onlinepubs/9799919799/functions/V2_chap02.html#tag_16_04_03_01

Message #11 received at 74788 <at> debbugs.gnu.org (full text, mbox):

From: Sachin T <sachintu47 <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 74788 <at> debbugs.gnu.org
Subject: Re: bug#74788: Incorrect return value for SIGPIPE case
Date: Thu, 12 Dec 2024 22:28:55 +0530

[Message part 1 (text/plain, inline)]

Hi Paul,

Thank you for your response.

This issue has been observed in z/OS version 2.5 and later.

I am currently discussing it with the z/OS platform team.
As a workaround, we installed a signal handler for SIGPIPE that invokes
_exit(141).
Once the final changes are determined, I’ll propose a fix upstream.

Best regards,
Sachin



On Wed, Dec 11, 2024 at 11:24 PM Paul Eggert <eggert <at> cs.ucla.edu> wrote:

> On 2024-12-11 04:59, Sachin T wrote:
> > Could you suggest the preferred solution for handling this situation on
> the
> > z/OS platform?
>
> Since this problem afflicts many applications (not just grep), the
> preferred solution would be to fix z/OS so that a process terminated by
> a signal has the exit status corresponding to the signal, even if the
> signal arrives during calls by 'exit' to functions registered by
> 'atexit'. This is required by POSIX[1] and is what other systems do. Is
> that something you could start the ball rolling on? (I don't use z/OS
> and so cannot file bug reports for it.)
>
> I don't see any straightforward change to 'grep' that would work around
> the z/OS problem. However, if you can think of a change, please let us
> know.
>
> Also, could you please let us know the z/OS version so that I can
> document this portability problem in Gnulib? Thanks.
>
> [1]:
>
> https://pubs.opengroup.org/onlinepubs/9799919799/functions/V2_chap02.html#tag_16_04_03_01
>

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.