Jim Meyering wrote: > Salvo Tomaselli wrote: >> Package: coreutils >> Version: 8.5-1 >> Severity: normal >> File: /usr/bin/tac >> >> Tac aborts when using it on a particular file. >> >> *** glibc detected *** tac: double free or corruption (top): >> 0x00000000025c5030 *** > ... > > Thank you for the report! > That is indeed a bug in the very latest. > > For a stand-alone, minimal demonstrator, run this: > > valgrind tac <(printf %0$((2**14 + 1))d 0) > /dev/null > > It prints this: > > Invalid free() / delete / delete[] > at 0x4A04D72: free (vg_replace_malloc.c:325) > by 0x402294: main (tac.c:669) > Address 0x4c30040 is 0 bytes inside a block of size 16,388 free'd > at 0x4A05255: realloc (vg_replace_malloc.c:476) > by 0x4117B8: xrealloc (xmalloc.c:57) > by 0x401A68: tac_seekable (tac.c:319) > by 0x402379: main (tac.c:515) > > Here is a fix: > >>From b3959fc691e606857a3c6e9b316ec34819972245 Mon Sep 17 00:00:00 2001 > From: Jim Meyering <meyer...@redhat.com> > Date: Sat, 28 Aug 2010 17:45:29 +0200 > Subject: [PATCH] tac: avoid double free > > * src/tac.c (main): Reading a line longer than 16KiB would cause > tac to realloc its primary buffer. Then, just before exit, tac > would mistakenly free the original (now free'd) buffer. > This bug was introduced by commit be6c13e7, "maint: always free a > buffer, to avoid even semblance of a leak". > * NEWS (Bug fixes): Mention it. > * tests/misc/tac (double-free): New test, to exercise this. > Reported by Salvo Tomaselli in <http://bugs.debian.org/594666>.
This was fixed long ago. Marking as "done".