Description of problem: Scripts that set COMP_WORDBREAKS sometimes die or hang Version-Release number of selected component (if applicable): bash-3.2-22.fc9.i386 How reproducible: create and run a script, called say cw_test, that contains the following: echo A COMP_WORDBREAKS=${COMP_WORDBREAKS//:} echo B 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 3. ./cw_test 4. repeat step 3 if it worked Actual results: 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 or *** glibc detected *** -bash: double free or corruption (out): 0x09cb8370 *** followed by a backtrace 3)it hangs have to Ctrl-Z kill -9 %1 Expected results: A B Additional info: 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 assignment above.
Created attachment 306162 [details] patch 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 cd /usr/src/redhat/SPECS rpmbuild -bp bash.spec cd .. 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 cd SPECS rpmbuild --short-circuit -bc bash.spec rpmbuild --short-circuit -bi bash.spec The bash binary was created in /var/tmp/bash-3.2-22.fc9-root-root/bin/bash I just copied this binary to /bin/bash for testing.
Hello Jeremy, > 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.
Hi Stepan, 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 coming from.
Created attachment 306368 [details] quick and dirty patch The patch by skasal is a workaround. The real problem is rl_completer_word_break_characters 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 specific issue?
Upstream know about this issue and in next release of bash this will be fixed.