Bug 189663

Description of problem:
With environment variable LANG=en_US.UTF-8 and the pr command with the "-m"
option, if one of the files to be merged contains a tab character, glibc
generates the error "*** glibc detected *** pr: free(): invalid next size
(fast): 0x000000000050e070 ***" and pr aborts.  Note that with LANG=C, the error
does not occur.

Version-Release number of selected component (if applicable):
coreutils-5.93-7.2.x86_64.rpm

How reproducible:
Always

Steps to Reproduce:
1. echo -e "\t" > X
2. cat /dev/null > Y
3. pr -m X Y
  
Actual results:
pr generates output and aborts while cleaning up.  The output generated before
the abort appears to be correct.  I will provide backtrace and memory map as an
attachment.

Expected results:
pr execution completes successfully without aborting and generates the expected
merged output.

Additional info:
- I am running with all updates released as of 21-Apr-2006.

- Using the following steps (files without a tab character) works as expected:
1. echo "A" > X
2. echo "B" > Y
3. pr -m X Y

- I traced the cause of the error to the "free (clump_buff);" call on line 3100
of coreutils-5.93/src/pr.c, but clump_buff is not NULL at that point.

- Looking further into the pr.c code, I saw interaction with the clump_buff
buffer that is apparently designed to work with multi-byte characters.  That led
to the discovery that LANG=en_US.UTF-8 causes the error but LANG=C works as
expected.

Fixed in CVS.

Please try this test update:

https://www.redhat.com/archives/fedora-test-list/2006-May/msg00175.html

Does that fix the problem for you?

Yes, the update solves the problem.

Not sure of the Bugzilla protocol -- I couldn't find any information on
reporters closing their own bugs.  Please e-mail me if I'm not supposed to do this.

Fixed for me in coreutils-5.95-1.1 -- Apparently another fix was made to pr for
multibyte locales in coreutils-5.95-1.3