Changing window size via bind -x may cause bash to hang in futex() call
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-unknown-linux-gnu'
-DCONF_VENDOR='unknown' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash'
-DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -march=x86-64
-mtune=generic -O2 -pipe
-DDEFAULT_PATH_VALUE='/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin'
-DSTANDARD_UTILS_PATH='/usr/bin:/bin:/usr/sbin:/sbin'
-DSYS_BASHRC='/etc/bash.bashrc' -DSYS_BASH_LOGOUT='/etc/bash.bash_logout'
uname output: Linux golem 2.6.37-ARCH #1 SMP PREEMPT Fri Feb 18 18:32:16 CET
2011 x86_64 AMD Phenom(tm) II X4 955 Processor AuthenticAMD GNU/Linux
Machine Type: x86_64-unknown-linux-gnu
Bash Version: 4.2
Patch Level: 0
Release Status: release
Description: When the size of an XTerminal is changed via a keybinding
(either by issuing an escape sequence or by an external
program that uses xlib) then sometimes bash will simply hang
before redrawing the prompt, not responding to C-c
anymore. I've used strace to verify that it's not the terminal
but indeed bash that seems to hang, apparently in a
futex(...FUTEX_WAIT...) call.
Repeat-By:
test script (test_resize.bash):
---snip---
dostuff () {
for((i=0; i<1000; i++)) {
echo "$i";
}
}
bind -x '"\ea": echo -ne "\e[8;12;80t"; dostuff'
bind -x '"\es": echo -ne "\e[8;24;80t"; dostuff'
bind -x '"\ew": xdotool windowsize --usehints $WINDOWID 80 12; dostuff'
bind -x '"\eq": xdotool windowsize --usehints $WINDOWID 80 24; dostuff'
toggle_size_fast () {
while :; do
echo -ne "\e[8;12;80t"
echo -ne "\e[8;24;80t"
done
}
---snip---
$ strace -o strace.log bash --rcfile test_resize.bash
When I use either M-a/M-s to toggle the size via escape
sequences or M-q/M-w to toggle using xdotool the freeze will
eventually occur after a few times. The dostuff() part makes
it appear sooner, but it also happens without it (it is harder
to trigger it in that case, though). This happens regardless
of whether checkwinsize is set or not.
When I run toogle_size_fast, I get a lot of interrupted system
call messages, but the resizing happens alright, bash never
hangs and C-c exits the function as usual.
I've tested this in xterm, urxvt and lilyterm (vte-based),
with both bash 4.2.0 and bash 4.1.9.
This is the strace output of a hang triggered by M-q:
read(0, "\33", 1) = 1
read(0, "q", 1) = 1
write(2, "\r\33[K", 4) = 4
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, [INT CHLD], [], 8) = 0
pipe([3, 4])= 0
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
child_tidptr=0x7fec5c96c9d0) = 1255
setpgid(1255, 1255) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
close(3)= 0
close(4)= 0
ioctl(255, TIOCGPGRP, [1255]) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], WSTOPPED|WCONTINUED, NULL) =
1255
rt_sigprocmask(SIG_BLOCK, [CHLD TSTP TTIN TTOU], [CHLD], 8) = 0
ioctl(255, TIOCSPGRP, [1065]) = 0
rt_sigprocmask(SIG_SETMASK, [CHLD], NULL, 8) = 0
ioctl(255, SNDCTL_TMR_TIMEBASE or TCGETS, {B400 opost isig -icanon -echo
...}) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
--- SIGCHLD (Child exited) @ 0 (0) ---
wait4(-1, 0x7fffb9e736dc, WNOHANG|WSTOPPED|WCONTINUED, NULL) = -1 ECHILD (No
child processes)
rt_sigreturn(0x)= 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
--- SIGWINCH (Window changed) @ 0 (0) ---
ioctl(0, TIOCGWINSZ, {ws_row=24, ws_col=80, ws_xpixel=640, ws_ypixel=336}) = 0
mmap(NULL, 134217728, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1,
0) = 0x7fec537e7000
munmap(0x7fec537e7000, 8491008) = 0
munmap(0x7fec5800, 58617856)= 0
mprotect(0x7fec5400, 135168, PROT_READ|PROT_WRITE) = 0
futex(0x7fec5c0d8ea0, FUTEX_WAIT, 2, NULL) = ? ERESTARTSYS (To be restarted)
--- SIGINT (Interrupt) @ 0 (0) ---
rt_sigreturn(0x2) = -1 EINTR (Interrupted system call)
futex(0x7fec5c0d8ea0, FUTEX_WAIT, 2, NULL
Re: bash tab variable expansion question?
On Sat, Feb 26, 2011 at 10:49 PM, gnu.bash.bug wrote: > > Wow...I'ts good workaround: > > $ cd /tmp > $ echo ~+ > /tmp > > Thanks Andreas! > > A workaround is fine but is the 4.2 behavior bug or not? > //Michael > > > On 26 Feb, 09:09, Andreas Schwab wrote: > > "gnu.bash.bug" writes: > > > What do you mean? > > > > > ~-/. is no equal to $PWD > > > > If you want $PWD, you can use ~+/. > > > > Andreas. > > > > -- > > Andreas Schwab, sch...@linux-m68k.org > > GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 > > "And now for something completely different." > > -- Clark J. Wang
Re: bash tab variable expansion question?
2011/2/27 Clark J. Wang > > A workaround is fine but is the 4.2 behavior bug or not? > I agree...Would be nice if someone could confirm if this is a bug or not? I'm betting that this is a bug :-) //Michael
bad double-quoted pattern substitution in indexed arrays
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: x86_64-pc-linux-gnu-gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR
uname output: Linux diegom 2.6.34-gentoo-r12 #1 SMP Mon Nov 29 06:02:02
ART 2010 x86_64 Intel(R) Pentium(R) Dual CPU T2330 @ 1.60GHz
GenuineIntel GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 4.1
Patch Level: 7
Release Status: release
Description:
It's difficult to explain. Better see below the particular case I had.
I needed to assign the elements of an array to other, but with a preceding
single quote. The following is a simplified (yet illustrative) example.
declare -a array1=(a b c d e f) array2=()
array2=( "${array1[@]/#/'}" )
AFAIK (plus the man page), the syntax of pattern substitution is
${parameter/pattern/string}, where "string" is just that, a string. I
have also
tried the following:
array2=( "${array1[@]/#/"'"}" )
But that caused a literal preceding "'", which technically is ok.
The ugly solution I had to take was a for loop. Nothing stressing but
bothers.
BASH shouldn't have treated specially the single quote after the slash and
before the closing brace (I think).
Actual Results:
Nothing actually, just the PS2 wating for a closing single quote.
Expected Results:
'a 'b 'c 'd 'e 'f
Repeat-By:
(Always Reproducible.)
declare -a my_array=(a b c d e)
echo "${my_array[@]/#/'}"
Fix:
None really, but two workarounds:
1) Using a for loop.
2) Declaring a variable, assigning it a single quote and expanding it
in the
"string" part of the substitution:
$ q="'"
$ echo "${my_array[@]/#/$q}"
(Proposed by Ulrich Müller)
This is discussed in Gentoo's bugzilla in bug #356403
--
Diego Augusto Molina
diegoaugustomol...@gmail.com
Manual: parentheses mismatch in '6.7 Arrays'
Dear developers, I read the page of the BASH manual about Arrays (http://www.gnu.org/software/bash/manual/html_node/Arrays.html#Arrays) today and found a parentheses mismatch in the first paragraph in the following part: (including arithmetic expressions (see Shell Arithmetic) Which should instead read: (including arithmetic expressions (see Shell Arithmetic)) Please fix it. Christophe
Re: bash tab variable expansion question?
On 2/27/11 8:39 AM, Clark J. Wang wrote: > On Sat, Feb 26, 2011 at 10:49 PM, gnu.bash.bug > wrote: > >> >> Wow...I'ts good workaround: >> >> $ cd /tmp >> $ echo ~+ >> /tmp >> >> Thanks Andreas! >> >> > A workaround is fine but is the 4.2 behavior bug or not? It's a more-or-less unintended consequence of the requested change Eric Blake referred to earlier in the thread. Bash-4.1 expanded shell variables in filename completion both internally and externally: it had to expand the directory name internally so it knew the correct directory name to pass to opendir(); and it used the same expansion externally, making the expanded directory name part of the completed filename it inserted into the line. When readline is completing filenames, and there are characters in the expanded filename that are contained in the value of the rl_completer_quote_characters, readline quotes the filename before inserting it. Since the filename was expanded, any special characters appearing in it were part of the filename read from the file system and should be quoted. Bash-4.2 performs the same internal expansion, but keeps the directory name the user typed in the filename it inserts into the command line. The `$' is quoted because it's a character bash treats specially, and it needs to be quoted when it appears as part of what readline thinks is a filename. The question is how to tell readline that the `$' should be quoted under some circumstances but not others. There's no hard-and-fast rule that works all the time, though I suppose a call to stat(2) before quoting would solve part of the problem. I will have to give it more thought. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
