segfault on rl_completion_matches() interrupt

2013-04-14 Thread Raphaël Droz
Using both 4.2 and 4.3, I can reproduce a segfault on completion (though
not using gdb)

This can happen very consistently using a time-consuming completion like
the one for `man`, eg:
$ man g^C


Attached is the trace from a core-file using `man gpg-agent g^C`
with bash 4.3.


Side note: as more and more completions take time to finish (think ssh,
dpkg, ...), having ^G to interrupt the completion process and not having
to use ^C which discard the whole line could be useful.
Core was generated by `comp/dev/bash/bash'.
Program terminated with signal 11, Segmentation fault.
#0  0x004a0b12 in rl_completion_matches (text=0x1d858d8 "g", 
entry_function=0x468b60 ) at complete.c:2142
2142  match_list[++matches] = string;
#0  0x004a0b12 in rl_completion_matches (text=0x1d858d8 "g", 
entry_function=0x468b60 ) at complete.c:2142
i = 
match_list_size = 0
match_list = 0x0
matches = 1
string = 0x1e452e8 "gnokii"
#1  0x0046eca0 in attempt_shell_completion (text=0x1d858d8 "g", 
start=14, end=15) at bashline.c:1514
s = 0
e = 15
s1 = 0
e1 = 3
os = 14
foundcs = 1
n = 
in_command_position = 0
ti = 
saveti = 
qc = -1
dflags = 
matches = 
command_separator_chars = 0x4be18b ";|&{(`"
#2  0x004a0c18 in gen_completion_matches (text=0x1d858d8 "g", 
start=, end=, our_func=0x49f5c0 
, 
found_quote=, quote_char=) at complete.c:1162
matches = 
#3  0x004a16cb in rl_complete_internal (what_to_do=63) at 
complete.c:1955
matches = 
our_func = 0x49f5c0 
start = 14
end = 
delimiter = 0
found_quote = 0
i = 
nontrivial_lcd = 
text = 0x1d858d8 "g"
saved_line_buffer = 0x1b026a8 "man gpg-agent g"
quote_char = 0 '\000'
tlen = 
mlen = 
#4  0x00498871 in _rl_dispatch_subseq (key=9, map=0x6f3920 
, got_subseq=0) at readline.c:820
r = 0
newkey = 
func = 0x4a1b60 
cxt = 
#5  0x0049901f in readline_internal_char () at readline.c:592
lastc = 9
eof_found = 0
c = 
code = 
lk = 0
#6  0x0049951d in readline_internal_charloop () at readline.c:619
eof = 
#7  readline_internal () at readline.c:633
eof = 1
#8  readline (prompt=) at readline.c:364
value = 0x0
#9  0x004250ac in yy_readline_get () at ./parse.y:1442
old_sigint = 0x45fce0 
line_len = 
c = 
#10 0x00426eee in yy_getc () at ./parse.y:1376
No locals.
#11 shell_getc (remove_quoted_newline=1) at ./parse.y:2244
i = 0
c = 
truncating = 0
uc = 
#12 0x00429c86 in read_token (command=0) at ./parse.y:2947
character = 
peek_char = 
result = 
#13 0x0042c6db in yylex () at ./parse.y:2556
No locals.
#14 yyparse () at y.tab.c:2031
yystate = 
yyerrstatus = 
yyssa = {0, 66, 95, 0, 10696, 432, 0, 0, 0, 0, 304, 0, 17672, 477, 0, 
0, -7233, 76, 0, 0, 17672, 477, 0, 0, -7233, 76, 291, 0, 17608, 477, 0, 0, 
-28501, 75, 0, 
  0, 0, 0, 0, 0, 19272, 477, 0, 0, 0, 0, 0, 0, -28501, 75, 0, 0, 
-21360, -4014, 32767, 0, 1, 0, 0, 0, -5230, 69, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 
9, 0, 0, 0, 
  -17804, 75, 0, 0, 2437, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 24617, 71, 
0, 0, -17277, 75, 603, 0, -17400, 268, 0, 0, 17544, 477, 0, 0, -11662, 75, 0, 
0, 0, 0, 
  2554, 0, 9992, 432, 0, 0, 17544, 477, 0, 0, -17400, 268, 0, 0, 17384, 
477, 0, 0, -11662, 75, 0, 0, -15480, 267, 2511, 0, 17544, 477, 0, 0, 1, 0, 0, 
0, 17544, 
  477, 0, 0, 0, 0, 0, 0, 28488, 287, 0, 0, -28501, 75, 0, 0, 0, 0, 0, 
0, 1, 0, 0, 0, -3524, 66, 0, 0, 0, 0, 0, 0, 17384, 477, 0, 0, 12296, 335, 0, 0, 
5616, 0, 
  0, 0, 0, 0, 0, 0, -9792, 111, 0, 0}
yyss = 0x7052abf0
yyssp = 0x7052abf0
yyvsa = {{word = 0x0, number = 0, word_list = 0x0, command = 0x0, 
redirect = 0x0, element = {word = 0x0, redirect = 0x482bb0 }, 
pattern = 0x0}, 
  {word = 0x10cda28, number = 17619496, word_list = 0x10cda28, command 
= 0x10cda28, redirect = 0x10cda28, element = {word = 0x10cda28, redirect = 
0x482bfd}, 
pattern = 0x10cda28}, {word = 0x, number = -1, word_list = 
0x, command = 0x, redirect = 0x, element = {word = 
0x, 
  redirect = 0x435726 }, pattern = 
0x}, {word = 0x0, number = 0, word_list = 0x0, command = 0x0, redirect 
= 0x0, element = {
  word = 0x0, redirect = 0x11185c8}, pattern = 0x0}, {word = 0x0, 
number = 0, word_list = 0x0, command = 0x0, redirect = 0x0, element = {word = 
0x0, 
  redirect = 0x}, pattern = 0x0}, {word = 0x, 
number = -1, word_list = 0x, command = 0x, redirect = 
0x, element = {
  word 

Re: segfault on rl_completion_matches() interrupt

2013-04-14 Thread Chet Ramey
On 4/14/13 7:08 PM, Raphaël Droz wrote:
> Using both 4.2 and 4.3, I can reproduce a segfault on completion (though
> not using gdb)

Thanks for the report.  I will look at this for bash-4.3.

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/



Re: segfault on rl_completion_matches() interrupt

2013-04-14 Thread Roman Rakus

On 04/15/2013 01:08 AM, Raphaël Droz wrote:

Using both 4.2 and 4.3, I can reproduce a segfault on completion (though
not using gdb)

This can happen very consistently using a time-consuming completion like
the one for `man`, eg:
$ man g^C


Attached is the trace from a core-file using `man gpg-agent g^C`
with bash 4.3.


Side note: as more and more completions take time to finish (think ssh,
dpkg, ...), having ^G to interrupt the completion process and not having
to use ^C which discard the whole line could be useful.

From quick look I see missing memory allocation and probably dislocation.

RR



Re: trap EXIT in piped subshell not triggered during wait

2013-04-14 Thread Chet Ramey
On 4/13/13 1:35 AM, Ilya Basin wrote:
> Hi!
> I've got strange behavior. Here's my script:
> 
> #!/bin/bash
> {
> trap '
> echo "in trap EXIT">&2
> ' EXIT
> sleep 4 &
> echo 'sleep 2'>&2
> sleep 2
> echo 'wait $!'>&2
> wait $!
> echo 'exit'>&2
> exit
> } | cat
> 
> If I press Ctrl-C during wait, the trap isn't triggered.
> If I replace curly brackets with round brackets, it works. What's the
> difference?

Thanks for the report.  This was fixed a few months ago and the fix is in
the devel branch.

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/