Re: realloc: start and end chunk sizes differ - rl_extend_line_buffer in lib/readline/util.c
On 1/7/19 5:10 AM, Eduardo A. Bustamante López wrote: > diff -ruN bash-5.0-rc1.orig/lib/readline/search.c > bash-5.0-rc1/lib/readline/search.c > --- bash-5.0-rc1.orig/lib/readline/search.c 2019-01-03 13:14:43.428392927 > -0800 > +++ bash-5.0-rc1/lib/readline/search.c 2019-01-07 01:39:44.245179141 -0800 > @@ -255,6 +255,8 @@ >rl_maybe_unsave_line (); >rl_clear_message (); >rl_point = cxt->save_point; > + if (rl_point > rl_end) > +rl_point = rl_end; >rl_mark = cxt->save_mark; >rl_restore_prompt (); Thanks for the catch. > I wonder if this should be a macro or if there is a better way to ensure that > rl_point is never greater than rl_end. This is why _rl_fix_point (int x) exists. Call it with a non-zero value for x if you want it to validate and fix up rl_mark also. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
bash-5.0_p1: wildcard expansion bug with unreadable intermediate directories
When expanding a wildcard following a partially quoted pathname, expansion fails if an intermediate directory is not readable, even when the final directory (the one in which expansion is performed) is readable. This does not occur if quotes are not used in the pathname, or if the quoted part of the pathname does not cross an unreadable directory (compare second and third expansions in the commands below). This does not occur in unpatched bash-5.0. Test case: bash-5.0$ mkdir -m700 /tmp/a /tmp/a/b bash-5.0$ touch /tmp/a/b/c bash-5.0$ echo /tmp/a/b/* "/tmp/a/"b/* "/tmp/a/b"/* /tmp/a/b/c /tmp/a/b/c bash-5.0$ chmod -r /tmp/a bash-5.0$ echo /tmp/a/b/* "/tmp/a/"b/* "/tmp/a/b"/* /tmp/a/b/c /tmp/a/b/* Note how the third expansion in the last command fails even though /tmp/a/b is readable. --Andrew Church http://achurch.org/
Re: bash-5.0_p1: wildcard expansion bug with unreadable intermediate directories
>When expanding a wildcard following a partially quoted pathname, [...] >Test case: I edited the commands in the test case when an additional thought occurred to me (the a/"b vs. a/b" distinction) but forgot to update the corresponding output lines. My apologies. Proper test case: bash-5.0$ chmod 700 /tmp/a bash-5.0$ rm -r /tmp/a bash-5.0$ mkdir -m700 /tmp/a /tmp/a/b bash-5.0$ touch /tmp/a/b/c bash-5.0$ echo /tmp/a/b/* "/tmp/a/"b/* "/tmp/a/b"/* /tmp/a/b/c /tmp/a/b/c /tmp/a/b/c bash-5.0$ chmod -r /tmp/a bash-5.0$ echo /tmp/a/b/* "/tmp/a/"b/* "/tmp/a/b"/* /tmp/a/b/c /tmp/a/b/c /tmp/a/b/* --Andrew Church http://achurch.org/
Re: Segmentation fault in lib/readline/text.c rl_change_case
On 1/6/19 9:25 PM, Eduardo A. Bustamante López wrote: > I found the issue with AFL (http://lcamtuf.coredump.cx/afl/). > > The crash itself happens due to the following: > > dualbus@system76-pc:~/src/gnu/bash$ cat -n lib/readline/text.c | sed -n > '1455,1460p' > 1455 mlen = wcrtomb (mb, nwc, &mps); // <- mlen is > -1, due to `nwc' being an invalid character. > 1456 if (mlen > 0) > 1457mb[mlen] = '\0'; > 1458 /* what to do if m != mlen? adjust below */ > 1459 /* m == length of old char, mlen == length of new > char */ > 1460 s = rl_line_buffer + start; > > dualbus@system76-pc:~/src/gnu/bash$ cat -n lib/readline/text.c | sed -n > '1475,1480p' > 1475 rl_extend_line_buffer (mlen - m + 1); > 1476 memmove (s + mlen, s + m, (e - s) - m); > 1477 memcpy (s, mb, mlen); // <- mlen is negative > here, thus it's an invalid `memcpy' > 1478 next += mlen - m; /* next char changes */ > 1479 end += mlen - m; /* end of word changes > */ > 1480 rl_end += mlen - m; /* end of line changes > */ > > I'm not really sure how to fix this problem. I worked around it by changing > the > condition in L1456 to just return early from the function. It's interesting that towupper returns a valid wide character in the zh_CN.gbk locale, but one that can't be converted back to a multibyte byte sequence. I didn't really think that was possible. I'll figure out some workaround that will probably involve reverting back to the original character. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: Unexpected delay in using arguments.
Just to confirm that the delays were removed on the release version. Thanks Chet Ramey () wrote: In the development distributions, always available at > > http://git.savannah.gnu.org/cgit/bash.git/snapshot/bash-devel.tar.gz > > Or you could just clone the git tree. > Many thanks, found and used. I'm going to assume you're running the pre-release distributions on a > Linux system where the debugging code in the bash malloc is enabled. > Yes, a debian based linux system. I am not sure about the debugging code, but it seems like it was the source of the delay. Now, all the delays (using 5.0.2(2)-release) are gone. > So I'm comfortable saying there's no big performance issue here. > Yes, I am confirming this, thanks.
