Your message dated Thu, 5 Jun 2014 23:51:19 +0200 with message-id <[email protected]> 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 [email protected] immediately.) -- 720352: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=720352 Debian Bug Tracking System Contact [email protected] 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 [email protected] http://www.aurel32.net
--- End Message ---
