(gdb) r
Starting program: /home/dualbus/src/gnu/bash/bash
bash-4.4$ PS4='$[T[$]]'; set -x
bash-4.4$ :
bash: $: syntax error: operand expected (error token is "$")
Program received signal SIGSEGV, Segmentation fault.
0x555b15ce in evalerror (msg=0x5565aa95 "syntax error in
expression")
(gdb) r -nvc 'for ((;)) do :; done&'
Starting program: /home/dualbus/src/gnu/bash/bash -nvc 'for ((;)) do :; done&'
for ((;)) do :; done&
/home/dualbus/src/gnu/bash/bash: -c: line 0: syntax error: arithmetic
expression required
/home/dualbus/src/gnu/bash/bash: -c: line 0: syntax error: `((;))'
Pro
On Wed, May 3, 2017 at 9:40 AM, Eduardo Bustamante wrote:
[...]
Here are more cases, which seem to just be variations that trigger the
same bug on different paths:
dualbus@debian:~/bash-fuzzing/bash-parser$ for f in minimized/*; do
printf '\n\n%s\n' ---; cat -v "$f"; printf '\n%s\n' ---; xxd "$f
Yes, the devel one does work. Sorry for the confusion.
It is the first time I see master as stable.
Would the fix be backported to stable?
Em qua, 3 de mai de 2017 às 19:33, Chet Ramey
escreveu:
> On 5/3/17 6:07 PM, Luiz Angelo Daros de Luca wrote:
> > Strange... I still get 0
>
> Yes, that's n
On 5/3/17 6:07 PM, Luiz Angelo Daros de Luca wrote:
> Strange... I still get 0
Yes, that's not the devel branch.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.
On Wed, May 3, 2017 at 5:07 PM, Luiz Angelo Daros de Luca
wrote:
> Strange... I still get 0
>
> $ git clone https://git.savannah.gnu.org/git/bash.git
[...]
git checkout devel
Strange... I still get 0
$ git clone https://git.savannah.gnu.org/git/bash.git
$ cd bash/
$ ./configure
$ make
$ ./bash testtrap.bash
18173:err=0 (should be 2)
$ ./bash --version
GNU bash, version 4.4.12(1)-release (x86_64-unknown-linux-gnu)
Copyright (C) 2016 Free Software Foundation, Inc.
Licens
On 5/3/17 9:26 AM, Eduardo Bustamante wrote:
> dualbus@debian:~/src/gnu/bash$ xxd ../cases/1
> : 3010 1f0e0...
>
> dualbus@debian:~/src/gnu/bash$ cat -A ../cases/1
> 0^P^_^N
>
> To reproduce,
>
> - run: ./bash -c 'read -e' # it doesn't seem to happen for i
On Wed, May 3, 2017 at 4:30 PM, Eduardo Bustamante
wrote:
>
> I think this was fixed as a consequence of the following thread:
> https://lists.gnu.org/archive/html/bug-bash/2017-03/msg00092.html
>
> In this commit:
> http://git.savannah.gnu.org/cgit/bash.git/commit/?h=devel&id=
> f698849a75fc7814
On 5/3/17 10:30 AM, Eduardo Bustamante wrote:
> I think this was fixed as a consequence of the following thread:
> https://lists.gnu.org/archive/html/bug-bash/2017-03/msg00092.html
>
> In this commit:
> http://git.savannah.gnu.org/cgit/bash.git/commit/?h=devel&id=f698849a75fc781472806182c3dc93007
dualbus@debian:~/src/gnu/bash$ cat -v ~/segfault
0 i[$($(0(){a[$(($(0)))}>))
dualbus@debian:~/src/gnu/bash$ xxd ~/segfault
: 3020 695b 2428 2428 3028 297b 615b 2428 0 i[$($(0(){a[$(
0010: 2824 2830 2929 297d 3e29 29 ($(0)))}>))
dualbus@debian:~/src/gnu/bash$ ./bash -n ~
On 5/2/17 9:07 PM, Luiz Angelo Daros de Luca wrote:
> Hi Chet,
>
> Is there any news on this? I noticed that Bash-4.4 patch 11 do touches
> something related to
> signals, subshell and command substitution but I still get the same
> behavior on 4.4.12(1)-release (x86_64-suse-linux-gnu)
>
> I came
On Wed, May 3, 2017 at 8:59 AM, Jesper Nygårds wrote:
> The following snippet is shows that if the readline
> option completion-ignore-case is turned on, the nosort option to complete
> has no effect:
I'm unable to reproduce this using the code from the devel branch:
bash-4.4$
GNU bash, version
The following snippet is shows that if the readline
option completion-ignore-case is turned on, the nosort option to complete
has no effect:
bind "set completion-ignore-case on"
_foo() {
COMPREPLY=( zoo noo boo )
return 0
}
complete -o nosort -F _foo foo
With the ignore-case option turn
On Wed, May 3, 2017 at 8:27 AM, Chet Ramey wrote:
> Both waits should return the same exit status. Using `builtin' should not
> conceal that aspect of wait's behavior.
FWIW, I can reproduce this in the latest devel branch:
dualbus@debian:~/src/gnu/bash$ ./bash -c 'trap : TERM; { sleep 1; kill
$$
On 5/2/17 8:33 PM, Luiz Angelo Daros de Luca wrote:
> Both waits should return 138? I detected this while trying to replace wait
> with a function in order to
> ignore when it returned because of a signal (with a very ugly hack). So,
> the "builtin wait" behavior
> was exactly the one I was trying
dualbus@debian:~/src/gnu/bash$ xxd ../cases/1
: 3010 1f0e0...
dualbus@debian:~/src/gnu/bash$ cat -A ../cases/1
0^P^_^N
To reproduce,
- run: ./bash -c 'read -e' # it doesn't seem to happen for interactive bash
- then type the following sequence: 0 \C-p \C-_
17 matches
Mail list logo
