Red Hat Bugzilla – Bug 446420
bash sometimes dies or hangs when COMP_WORDBREAKS set
Last modified: 2014-01-12 19:07:25 EST
Description of problem:
Scripts that set COMP_WORDBREAKS sometimes die or hang
Version-Release number of selected component (if applicable):
create and run a script, called say cw_test, that contains the following:
NOTE:COMP_WORDBREAKS="" will do just as well.
Steps to Reproduce:
1. create the cw_test script with the 3 lines above
2. chmod 755 cw_test
4. repeat step 3 if it worked
Variable but in general 1 of 3 things happens.
1)it works ok
2)*** glibc detected *** -bash: munmap_chunk(): invalid pointer: 0x09cb8370 ***
followed by a backtrace
*** glibc detected *** -bash: double free or corruption (out): 0x09cb8370 ***
followed by a backtrace
have to Ctrl-Z
kill -9 %1
It appears that bash is trying to free a pointer that is not always set.
If a script just does 'echo "CW=$COMP_WORDBREAKS"' it comes back with different
values some of which seem to be bits of memory from other parts of bash.
If run using '/bin/bash cw_test' or if #!/bin/bash is placed at the start the
script works fine.
I noticed this problem as I often use '. /etc/profile' in scripts and noticed
that sometimes my scripts were failing. It turned out that the
/etc/profile.d/gvfs-bash-completion.sh script contains the COMP_WORDBREAKS
Created attachment 306162 [details]
this patch should fix the problem: the variable COMP_WORDBREAKS should not be
special (dynamic) at all when running in non-interactive mode. (readline is
not initialized if the shell is not interactive.)
Beware, I haven't tested the patch yet!
I rebuilt bash with your patch applied and it seems to be ok.
I'm not sure about my build method though as the bash binary produced is 749832
bytes when the original was 755624.
My build method was:-
rpm -Uvh bash-3.2-22.fc9.src.rpm
rpmbuild -bp bash.spec
patch -p1 < /tmp/bash.patch #where bash.patch is your patch file
#I had to enter the path to variables.c to get the patch to apply
rpmbuild --short-circuit -bc bash.spec
rpmbuild --short-circuit -bi bash.spec
The bash binary was created in
I just copied this binary to /bin/bash for testing.
> I'm not sure about my build method
I would say that a good check would be to use your build method _minus_ the
patch. If the binary built that way does segfault, then it is a good indication
that the patch touches the right spot. This test would be helpful; if you have
enough time to do it, of course.
I hope to test the patch tomorrow.
I have followed your suggestion and built bash without your patch.
The result is a version of bash 749832 bytes long(i.e. same as with the patch)
and this HAS the bug. So the patch seems to work well.
Oddly when I came in this morning I noticed that /bin/bash(built with the patch)
was 755624 bytes and was working fine. I have realised that the size difference
is caused by prelink, if I do 'prelink bash' on the 749832 bytes version it
becomes 755624 bytes long. So that explains where the difference in size was
Created attachment 306368 [details]
quick and dirty patch
The patch by skasal is a workaround. The real problem is
being freed when the shell reinitializes itself to run the script, but
not set to NULL after the free.
There will be a fix in the next bash release.
For now you can use this patch, but it's quick'n'dirty...
Patch is included in rawhide: bash-3.2-23.fc10
I have installed bash-3.2-23.fc10 and it seems to work fine.
A noticeable difference between this version and the previous patch is that if a
script echoes $COMP_WORDBREAKS in this version it has a valid value rather than
not being set.
Does the patch need to be made known to the GNU maintainers or is this a Fedora
Upstream know about this issue and in next release of bash this will be fixed.