Created attachment 128112 [details]
backtrace and memory map generated before abort
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):
Steps to Reproduce:
1. echo -e "\t" > X
2. cat /dev/null > Y
3. pr -m X Y
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
pr execution completes successfully without aborting and generates the expected
- 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
Fixed in CVS.
Please try this test update:
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