On 2008/04/20 12:14, Matthias Klose <[EMAIL PROTECTED]> wrote: > tag 465979 + moreinfo > thanks > > - please recheck with 3.2, > - is this reproducible with certain history content?
With 3.2, the bug is different - it does not hang anymore, it exits instead. Here is the stack trace with debugging symbols (3.1dfsg-8): #0 rl_search_history (direction=-1, invoking_key=18) at ../../../bash/lib/readline/isearch.c:638 #1 0x0000000000495ecb in rl_reverse_search_history (sign=1, key=18) at ../../../bash/lib/readline/isearch.c:137 #2 0x0000000000488b75 in _rl_dispatch_subseq (key=18, map=0x5dfac0, got_subseq=0) at ../../../bash/lib/readline/readline.c:718 #3 0x00000000004889aa in _rl_dispatch (key=5000824, map=0x5dfac0) at ../../../bash/lib/readline/readline.c:668 #4 0x00000000004886a9 in readline_internal_char () at ../../../bash/lib/readline/readline.c:500 #5 0x00000000004886ef in readline_internal_charloop () at ../../../bash/lib/readline/readline.c:526 #6 0x0000000000488718 in readline_internal () at ../../../bash/lib/readline/readline.c:540 #7 0x000000000048825b in readline (prompt=0x1ea8e08 "elftor:/home/max# ") at ../../../bash/lib/readline/readline.c:316 #8 0x000000000041da94 in yy_readline_get () at ../bash/parse.y:1216 #9 0x000000000041d9d7 in yy_getc () at ../bash/parse.y:1150 #10 0x000000000041e6b0 in shell_getc (remove_quoted_newline=1) at ../bash/parse.y:1939 #11 0x000000000041f589 in read_token (command=0) at ../bash/parse.y:2559 #12 0x000000000041ee44 in yylex () at ../bash/parse.y:2205 #13 0x000000000041b75c in yyparse () at y.tab.c:1933 #14 0x000000000041b412 in parse_command () at ../bash/eval.c:222 #15 0x000000000041b4d8 in read_command () at ../bash/eval.c:266 #16 0x000000000041b22e in reader_loop () at ../bash/eval.c:132 #17 0x0000000000418fa3 in main (argc=1, argv=0x7fff638f25e8, env=0x7fff638f25f8) at ../bash/shell.c:714 The endless loop is the "while" loop in rl_search_history(). When an i/o error occurs, _rl_isearch_dispatch() returns 1 in line 411. This happens _every_ time in the shell started by "su" (su with pam_wheel, without password). It never happens when bash is started by another process than "su". Even when I type "su -c 'nice bash'", the bug does not appear. For some reason, read(/dev/stdin) returns -1 with errno==EIO. There is another bug, which seems to have the same cause: after "su", when I type one characters, bash immediately executes the command although I havn't pressed enter: [EMAIL PROTECTED]:~$ su elftor:/home/max# a bash: a: command not found elftor:/home/max# I have pressed 4 keys on the keyboard: "su", enter, "a". No final enter. Unfortunately, it is impossible to strace or debug this one, because it does not occur if bash is ptraced. With bash 3.2, this is similar: [EMAIL PROTECTED]:~$ su -c /tmp/bash32 elftor:/home/max# aexit [EMAIL PROTECTED]:~$ Max -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
