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

Bug#720352: marked as done (tr: crash upon failed write(2))

Your message dated Thu, 5 Jun 2014 23:51:19 +0200
with message-id <20140605215119.GA18252@volta.rr44.fr>
and subject line Re: Bug#720352: fwrite: crash upon failed write(2)
has caused the Debian Bug report #720352,
regarding tr: crash upon failed write(2)
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
720352: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=720352
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: coreutils
Version: 8.21-1
Severity: normal

Dear Maintainer,
*** Please consider answering these questions, where appropriate ***

   Easiest way to reproduce:

   ~$ tr a b < /dev/zero > /dev/full
   zsh: segmentation fault (core dumped)  tr a b < /dev/zero > /dev/full

I first reproduced it on:

   ~$ tr a b < file 1<> file

where "file" was a sparse file and the filesystem was full. In
that other instance, I also observed "tr" outputting random data
to stdout actually corrupting the file.

/mnt# df -h .
Filesystem      Size  Used Avail Use% Mounted on
/dev/loop1      9.7M   92K  9.1M   1% /mnt
/mnt# truncate -s20M a
/mnt# tr a b < a 1<> a
zsh: segmentation fault  tr a b < a 1<> a
(139)/mnt# hd a
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
0098c400  01 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
0098c410  00 00 00 00 00 00 00 00  49 79 f2 5d ff 7f 00 00  |........Iy.]....|
0098c420  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
01400000


Valgrind shows:

==1521== Memcheck, a memory error detector
==1521== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==1521== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==1521== Command: tr a b
==1521==
==1521== Invalid read of size 8
==1521==    at 0x3FFC28789B: __GI_mempcpy (memcpy.S:272)
==1521==    by 0x3FFC278225: _IO_default_xsputn (genops.c:464)
==1521==    by 0x3FFC2768D2: _IO_file_xsputn@@GLIBC_2.2.5 (fileops.c:1356)
==1521==    by 0x3FFC270F24: fwrite_unlocked (iofwrite_u.c:46)
==1521==    by 0x40229B: ??? (in /usr/bin/tr)
==1521==    by 0x3FFC221994: (below main) (libc-start.c:260)
==1521==  Address 0x60d000 is not stack'd, malloc'd or (recently) free'd
==1521==
==1521==
==1521== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==1521==  Access not within mapped region at address 0x60D000
==1521==    at 0x3FFC28789B: __GI_mempcpy (memcpy.S:272)
==1521==    by 0x3FFC278225: _IO_default_xsputn (genops.c:464)
==1521==    by 0x3FFC2768D2: _IO_file_xsputn@@GLIBC_2.2.5 (fileops.c:1356)
==1521==    by 0x3FFC270F24: fwrite_unlocked (iofwrite_u.c:46)
==1521==    by 0x40229B: ??? (in /usr/bin/tr)
==1521==    by 0x3FFC221994: (below main) (libc-start.c:260)

And gdb from a "tr" compiled with -g -O0:

#0  __mempcpy_sse2 () at ../sysdeps/x86_64/memcpy.S:272
#1  0x0000003ffc278226 in __GI__IO_default_xsputn (f=f@entry=0x3ffc5a7160 <_IO_2_1_stdout_>, data=data@entry=0x60e300 <in_squeeze_set>, n=n@entry=8193) at genops.c:464
#2  0x0000003ffc2768d3 in _IO_new_file_xsputn (n=8192, data=<optimized out>, f=0x3ffc5a7160 <_IO_2_1_stdout_>) at fileops.c:1356
#3  _IO_new_file_xsputn (f=0x3ffc5a7160 <_IO_2_1_stdout_>, data=<optimized out>, n=8192) at fileops.c:1278
#4  0x0000003ffc270f25 in __GI_fwrite_unlocked (buf=<optimized out>, size=1, count=8192, fp=<optimized out>) at iofwrite_u.c:46
#5  0x0000000000404a37 in main (argc=3, argv=0x7ffff50c6d08) at src/tr.c:1938

ltrace:

read(0, "y\ny\ny\ny\ny\ny\ny\ny\ny\ny\ny\ny\ny\ny\ny\ny\n"...,
8192) = 8192
fwrite_unlocked("y\ny\ny\ny\ny\ny\ny\ny\ny\ny\ny\ny\ny\ny\ny\ny\n"...,
1, 8192, 0x3ffc5a7160 <unfinished ...>
<SEGV>

It could very will be a bug in eglibc as I can't really see
anything wrong with the tr code.

It also occurs with LC_ALL=C

It also occurs on Ubuntu 13.10 amd64, not on 12.04 amd64,
possibly pointing to eglibc 2.17.

I couldn't reproduce it with any other utility only "tr", but
then again, none of the other utilities I tried to run under
ltrace showed any call to fwrite_unlocked with more than a few
bytes..

I can't reproduce it with stdbuf -o3605 tr a b > /dev/full < /dev/zero
or any value below 3605, but I do with any value above that.


*** End of the template - remove these lines ***


-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (500, 'testing'), (50, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.10-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages coreutils depends on:
ii  libacl1      2.2.52-1
ii  libattr1     1:2.4.47-1
ii  libc6        2.17-92
ii  libselinux1  2.1.13-2

coreutils recommends no packages.

coreutils suggests no packages.

-- no debconf information

--- End Message ---
--- Begin Message --- 
Version: 2.19-1

On Tue, Aug 20, 2013 at 04:59:42PM -0600, Bob Proulx wrote:
> reassign 720352 libc6
> thanks
> 
> Dear libc6 Maintainers,
> 
> Stephane Chazelas opened a bug against coreutils tr about a core dump
> crash.  This was forwarded upstream.  Paul Eggert reduced it further
> to the smaller program that is attached showing that it is likely in
> libc.  I have reassigned this to the libc6 package.
> 

This bug has been fixed in version 2.19-1. Closing the bug for this 
version.

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                 http://www.aurel32.net

--- End Message ---
Reply to: