emacs-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[debbugs-tracker] bug#23031: closed (reporting write errors and handling


From: GNU bug Tracking System
Subject: [debbugs-tracker] bug#23031: closed (reporting write errors and handling SIGPIPE)
Date: Fri, 18 Mar 2016 17:30:02 +0000

Your message dated Fri, 18 Mar 2016 13:30:23 -0400
with message-id <address@hidden>
and subject line Re: bug#23031: reporting write errors and handling SIGPIPE
has caused the debbugs.gnu.org bug report #23031,
regarding reporting write errors and handling SIGPIPE
to be marked as done.

(If you believe you have received this mail in error, please contact
address@hidden)


-- 
23031: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=23031
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: reporting write errors and handling SIGPIPE Date: Wed, 16 Mar 2016 12:14:32 -0400 User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
Hello,

First,
Attached is a patch that adds errno information to 'write error' messages, e.g.:
      $ grep [...] > /dev/full
      grep: write error: No space left on device
I hope it is self-explanatory enough (comments and suggestions are welcomed).


Second,
On one gnu/linux server I'm experiencing a strange behavior (or at least, not 
understandable to me):
grep does not immediately terminates on SIGPIPE, and instead exits and prints "write 
error" (for EPIPE).
which is partially why I wrote the above patch, to try understand what's going 
on.

An example, reproducible on my machine (running on real hardware), though hard 
to reproduce inside a VM and on other servers:
   seq 100000 > in
   for i in $(seq 100) ; do
      ./src/grep -s --line-buffered -v '^$' < in | head -n1 > /dev/null ;
   done
for some of the runs  (out of 100) I get an error "./src/grep: write error: Broken 
pipe" .

attached are strace/ltrace logs of such cases. the key lines:

When grep is killed by SIGPIPE:

 == strace ==
   write(1, "1\n", 2)                      = 2
   write(1, "2\n", 2)                      = -1 EPIPE (Broken pipe)
   --- SIGPIPE {si_signo=SIGPIPE, si_code=SI_USER, si_pid=2960, si_uid=1004} ---
   +++ killed by SIGPIPE +++

 == ltrace ==
   fwrite_unlocked("1\n2\n3\n4\n5\n6\n7\n8\n9\n10\n11\n12\n13\n14"..., 1, 2, 
0x7efc5dab9400)     = 2
    __errno_location()                                                          
                  = 0x7efc5dee46a0
   fflush_unlocked(0x7efc5dab9400, 0x18da000, 10, 4096)                         
                 = 0
   memchr("2\n3\n4\n5\n6\n7\n8\n9\n10\n11\n12\n13\n14\n1"..., '\n', 32766)      
                 = 0x18da003
   fwrite_unlocked("2\n3\n4\n5\n6\n7\n8\n9\n10\n11\n12\n13\n14\n1"..., 1, 2, 
0x7efc5dab9400)     = 2
   __errno_location()                                                           
                 = 0x7efc5dee46a0
   fflush_unlocked(0x7efc5dab9400, 0x18da004, 0, 2610 <no return ...>
   --- SIGPIPE (Broken pipe) ---
   +++ killed by SIGPIPE +++


When grep is not killed by SIGPIPE:

 == strace ==
   write(1, "1\n", 2)                      = 2
   write(1, "2\n", 2)                      = -1 EPIPE (Broken pipe)
   --- SIGPIPE {si_signo=SIGPIPE, si_code=SI_USER, si_pid=2893, si_uid=1004} ---
   write(2, "./src/grep: ", 12)            = 12
   write(2, "write error", 11)             = 11
   write(2, ": Broken pipe", 13)           = 13
   write(2, "\n", 1)                       = 1
   exit_group(2)                           = ?

 == ltrace ==
   fwrite_unlocked("1\n2\n3\n4\n5\n6\n7\n8\n9\n10\n11\n12\n13\n14"..., 1, 2, 
0x7f9e62f50400)           = 2
   __errno_location()                                                           
                       = 0x7f9e6337b6a0
   fflush_unlocked(0x7f9e62f50400, 0x25af000, 10, 4096)                         
                       = 0
   memchr("2\n3\n4\n5\n6\n7\n8\n9\n10\n11\n12\n13\n14\n1"..., '\n', 32766)      
                       = 0x25af003
   fwrite_unlocked("2\n3\n4\n5\n6\n7\n8\n9\n10\n11\n12\n13\n14\n1"..., 1, 2, 
0x7f9e62f50400)           = 2
   __errno_location()                                                           
                       = 0x7f9e6337b6a0
   fflush_unlocked(0x7f9e62f50400, 0x25af004, 0, 2610 <no return ...>
   --- SIGPIPE (Broken pipe) ---
   <... fflush_unlocked resumed> )                                              
                       = 0xffffffff
   __errno_location()                                                           
                       = 0x7f9e6337b6a0
   error(2, 32, 0x41caa0, 32 <no return ...>



The server is:
  $ uname -a
  Linux x 3.13.0-77-generic #121-Ubuntu SMP Wed Jan 20 10:50:42 UTC 2016 x86_64 
GNU/Linux

  $ gcc -v
  Using built-in specs.
  COLLECT_GCC=gcc
  
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/5.2.0/lto-wrapper
  Target: x86_64-unknown-linux-gnu
  Configured with: ../gcc-5.2.0/configure --enable-languages=c,c++
  Thread model: posix
  gcc version 5.2.0 (GCC)


Thanks for any feedback,
regards,
 - assaf

Attachment: grep-write-error-msg.patch.xz
Description: application/xz

Attachment: grep-SIGPIPE-killed.ltrace.log.xz
Description: application/xz

Attachment: grep-SIGPIPE-killed.strace.log.xz
Description: application/xz

Attachment: grep-SIGPIPE-not-killed.ltrace.log.xz
Description: application/xz

Attachment: grep-SIGPIPE-not-killed.strace.log.xz
Description: application/xz


--- End Message ---
--- Begin Message --- Subject: Re: bug#23031: reporting write errors and handling SIGPIPE Date: Fri, 18 Mar 2016 13:30:23 -0400 User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
Hello,

On 03/17/2016 02:49 PM, Paul Eggert wrote:
On 03/16/2016 09:14 AM, Assaf Gordon wrote:
Attached is a patch that adds errno information to 'write error' messages

Thanks, I installed the attached somewhat-tweaked version of that. Among other things I 
renamed the new static functions to avoid confusion with existing "safer" 
functions.

This doesn't address the SIGPIPE mystery so I'll leave the bug report open, but 
my guess is that this part isn't really a grep bug.

Thanks for the inclusion and the additional information.
This is indeed not a bug in grep (and thus closed).

I found that on my weird setup, programs start with SIGPIPE set to SIG_IGN by 
default (not sure how I got myself into such situation).

regards,
 - assaf



--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]