On 5/23/24 9:09 PM, Grisha Levit wrote:
On Thu, May 23, 2024 at 3:55 PM Chet Ramey wrote:
On 5/23/24 7:43 AM, Michael Maurer wrote:
Bash Version: 5.2
Patch Level: 15
Release Status: release
Description:
Calling a function that itself uses the keyword "time" to call another
function
On Thu, May 23, 2024 at 3:55 PM Chet Ramey wrote:
>
> On 5/23/24 7:43 AM, Michael Maurer wrote:
>
> > Bash Version: 5.2
> > Patch Level: 15
> > Release Status: release
> >
> > Description:
> > Calling a function that itself uses the keyword "time" to call
> > another function that performs
On 5/23/24 7:43 AM, Michael Maurer wrote:
Bash Version: 5.2
Patch Level: 15
Release Status: release
Description:
Calling a function that itself uses the keyword "time" to call another
function that performs a long task, and then interrupting with Ctrl+C before it is
complete, causes a
On Fri, Jan 20, 2023 at 11:50:52PM +0100, Martin Schulte wrote:
> Hello Nicolas!
>
> > bash-5.1$ echo () { echo test }
> > > echo test
> > > }
> > bash-5.1$ echo
> Most probably you want to insert a ; before the first closing }:
>
> echo() { echo test ; }
>
> But even now bash w
Hello Nicolas!
> bash-5.1$ echo () { echo test }
> > echo test
> > }
> bash-5.1$ echo
You have defined a function echo that
- calls itself with the first argument 'test' and the second argument '}' (!!!)
- calls itself with the first and only argument test
Try
type -a echo
and
On Sat, 21 Jan 2023 at 09:24, N R wrote:
> I ran into a segmentation fault running bash --posix. Here are the
> steps to reproduce :
> bash-5.1$ echo () { echo test }
> > echo test
> > }
> bash-5.1$ echo
> Even though I'm not sure what is causing this seg fault, I'm sure i
On 1/20/23 2:35 PM, N R wrote:
Bash Version: 5.2
Patch Level: 15
Release Status: release
Description:
I ran into a segmentation fault running bash --posix. Here are the
steps to reproduce :
bash-5.1$ echo () { echo test }
> echo test
> }
bash-5.1$ echo
Even though
If you want some more interesting seg faults, here are some:
1)
bash-5.1$ (\${_@P};${_@P})
Segmentation fault (core dumped)
# golfed version of p='${p@P}'; : "${p@P}"
bash-5.1$ bash --norc
bash-5.1$ PS1=\${PS1@P}
Segmentation fault (core dumped)
bash-5.1$
# in an
On 8/31/22 3:58 PM, Евгений Штанов wrote:
Bash Version: 5.1
Patch Level: 16
Release Status: release
Description:
Hi! I was fuzzing bash with AFL++ and found segmentation fault.
Backtrace in in attachment
You have created an infinite loop sourcing the same file and run your
On 6/15/21 3:50 PM, Sibo Dong wrote:
Hello,
Running the fc builtin on an empty history list results in a
segmentation fault from bash.
Thanks for the report.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ra
On Sun, Jul 21, 2019 at 06:56:09PM -0400, Chet Ramey wrote:
(...)
> Thanks for the report. Look at match_wpattern and consider what happens if
> wmatchlen returns something longer than the string length. It will be fixed
> for the next devel branch push.
Aha! I see.
| Starting program: /tmp/bash/
On 7/20/19 6:23 PM, Eduardo A. Bustamante López wrote:
> Bash `devel' crashes under the following circumstances:
>
> | dualbus@system76-pc:/tmp/build-bash-devel$ CFLAGS='-O0 -ggdb'
> ~/src/gnu/bash/configure --with-bash-malloc
> | (...)
> | dualbus@system76-pc:/tmp/build-bash-devel$ make -j$(npro
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 =
On Mon, Jan 07, 2019 at 01:16:05AM -0800, Eduardo A. Bustamante López wrote:
> I found this with AFL. I think it's related to the problem reported here:
> http://lists.nongnu.org/archive/html/bug-bash/2018-09/msg00045.html
>
> debian@debian-fuzz:/mnt$ cat -A rl_do_undo
> ^RM-CM-!M-CM-CM-!M-C^[.^[^
On 9/22/18 3:01 PM, Eduardo A. Bustamante López wrote:
> Found via fuzzing (of `read -e') using AFL,
>
> To reproduce:
>
> In a shell with `emacs' readline mode, type:
>
> ~/
Thanks for the report.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
On 5/15/17 3:58 PM, Eduardo Bustamante wrote:
> bash-4.4$ "$[U[0S]+=]"
> bash: 0S: value too great for base (error token is "0S")
>
> It seems like the array index expression causes a longjmp in the
> second case, so it stops evaluating.
>
> Found by fuzzing.
>
> I think this might be similar t
On 5/15/17 3:20 PM, Eduardo Bustamante wrote:
> I think this is the fix:
Yeah, that looks right. I see what happened. Thanks.
> dualbus@debian:~/src/gnu/bash$ git diff -- bashline.c
> diff --git a/bashline.c b/bashline.c
> index 7884416a..c92255d6 100644
> --- a/bashline.c
> +++ b/bashline.c
>
On 2/10/17 12:15 AM, Tom wrote:
> Bash Version: 4.4
> Patch Level: 11
> Release Status: release
>
> Description:
> A segmentation fault occurs when nesting several thousand heredocs, as in
> the example in the Repeat-By section. I have tested this on several
> different distros, OSes
> $ bash-4.3.22 -c 'shopt -s lastpipe; trap -- "printf x" ERR; true | { true |
> false; }'
> xxSegmentation fault
>
> $ ./bash -c 'shopt -s lastpipe; trap -- "printf x" ERR; true | { true |
> false; }'
> xx./bash: wait_for: No record of process 7954
> x
Yeah, it will take a little longer to sup
On Tue, Aug 12, 2014 at 09:15:04AM -0400, Chet Ramey wrote:
> On 8/11/14, 2:21 PM, lolilolicon wrote:
> > The following code segfaults when run by bash 4.3.022
> >
> > set -E
> > shopt -s lastpipe
> > trap -- 'true' ERR
> > true | { true | false; }
>
> Here's a patch for those who would l
On 8/11/14, 2:21 PM, lolilolicon wrote:
> Sorry for the unhelpful title, but I can't find a one that isn't
> longer than the body of the mail.
>
> The following code segfaults when run by bash 4.3.022
>
> set -E
> shopt -s lastpipe
> trap -- 'true' ERR
> true | { true | false; }
>
> This
On 8/11/14, 3:05 PM, Geir Hauge wrote:
> And lastly, in interactive mode
> $ set +m; shopt -s lastpipe; trap -- "printf x" ERR; true | { true | false;
> }
> xxx
>
> Can't quite understand why it would trigger the ERR trap thrice.
That's easy enough to explain. The ERR trap is triggered wherever
On 8/11/14, 2:21 PM, lolilolicon wrote:
> Sorry for the unhelpful title, but I can't find a one that isn't
> longer than the body of the mail.
>
> The following code segfaults when run by bash 4.3.022
>
> set -E
> shopt -s lastpipe
> trap -- 'true' ERR
> true | { true | false; }
>
> This
2014-08-11 20:47 GMT+02:00 Greg Wooledge :
> On Tue, Aug 12, 2014 at 02:21:18AM +0800, lolilolicon wrote:
> > The following code segfaults when run by bash 4.3.022
> >
> > set -E
> > shopt -s lastpipe
> > trap -- 'true' ERR
> > true | { true | false; }
>
> I could not reproduce this, on HP
On Tue, Aug 12, 2014 at 02:21:18AM +0800, lolilolicon wrote:
> The following code segfaults when run by bash 4.3.022
>
> set -E
> shopt -s lastpipe
> trap -- 'true' ERR
> true | { true | false; }
I could not reproduce this, on HP-UX or Linux. I tried from an
interactive shell, just typin
On 2/5/14 10:51 PM, Dan Jacobson wrote:
> # su - nobody
> No directory, logging in with HOME=/
> $ cat /tmp/r
> LC_CTYPE=zh_TW.UTF-8 N=$(echo 統一|iconv -t big5 -f utf-8) sh -xc ': $N'
> $ sh /tmp/r
> /tmp/r: line 1: 4551 Segmentation fault LC_CTYPE=zh_TW.UTF-8 N=$(echo
> 統一|iconv -t big5 -f u
On 2/6/14 9:07 AM, Pierre Gaston wrote:
>
> With bash 3.2.25(1)-release
>
> $ LC_CTYPE=zh_TW.UTF-8 N=$(echo 統一|iconv -t big5 -f utf-8) sh -xc ': $N'
> + : $'\262\316\244@'
>
> With bash-rc1 I can reproduce it with: bash -xc $': \262\316\244@'
Thanks for the reproducer.
Chet
--
``The lyf so
What a clod I was, thinking @ was ^@.
OK glad you guys are hot on the trail.
Greg Wooledge writes:
> On Thu, Feb 06, 2014 at 11:51:25AM +0800, Dan Jacobson wrote:
>> # su - nobody
>> No directory, logging in with HOME=/
>> $ cat /tmp/r
>> LC_CTYPE=zh_TW.UTF-8 N=$(echo ??|iconv -t big5 -f utf-8) sh -xc ': $N'
>> $ sh /tmp/r
>> /tmp/r: line 1: 4551 Segmentation fault
On Thu, Feb 6, 2014 at 4:07 PM, Pierre Gaston wrote:
>
>
>
> On Thu, Feb 6, 2014 at 3:38 PM, Chet Ramey wrote:
>
>> On 2/5/14 10:51 PM, Dan Jacobson wrote:
>> > # su - nobody
>> > No directory, logging in with HOME=/
>> > $ cat /tmp/r
>> > LC_CTYPE=zh_TW.UTF-8 N=$(echo 統一|iconv -t big5 -f utf-8)
On Thu, Feb 6, 2014 at 3:38 PM, Chet Ramey wrote:
> On 2/5/14 10:51 PM, Dan Jacobson wrote:
> > # su - nobody
> > No directory, logging in with HOME=/
> > $ cat /tmp/r
> > LC_CTYPE=zh_TW.UTF-8 N=$(echo 統一|iconv -t big5 -f utf-8) sh -xc ': $N'
> > $ sh /tmp/r
> > /tmp/r: line 1: 4551 Segmentation
On Thu, Feb 06, 2014 at 11:51:25AM +0800, Dan Jacobson wrote:
> # su - nobody
> No directory, logging in with HOME=/
> $ cat /tmp/r
> LC_CTYPE=zh_TW.UTF-8 N=$(echo ??|iconv -t big5 -f utf-8) sh -xc ': $N'
> $ sh /tmp/r
> /tmp/r: line 1: 4551 Segmentation fault LC_CTYPE=zh_TW.UTF-8 N=$(ech
On 2/5/14 10:51 PM, Dan Jacobson wrote:
> # su - nobody
> No directory, logging in with HOME=/
> $ cat /tmp/r
> LC_CTYPE=zh_TW.UTF-8 N=$(echo 統一|iconv -t big5 -f utf-8) sh -xc ': $N'
> $ sh /tmp/r
> /tmp/r: line 1: 4551 Segmentation fault LC_CTYPE=zh_TW.UTF-8 N=$(echo
> 統一|iconv -t big5 -f u
On 1/9/13 1:15 PM, Eduardo A. Bustamante López wrote:
> Hi!
>
> I found an issue while using array variables in an arithmetical
> context. I tried to determine where the problem was, but I didn't
> understand expr.c. The backtrace points to expr.c's line 556, in
> expassing. I tested both the mast
On Wednesday, January 09, 2013 10:15:31 AM Eduardo A. Bustamante López wrote:
> Hi!
>
> I found an issue while using array variables in an arithmetical
> context. I tried to determine where the problem was, but I didn't
> understand expr.c. The backtrace points to expr.c's line 556, in
> expassing
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 19/04/2011 22:11, Chet Ramey wrote:
> The problem has to do with bad calculations of the last history entry.
> I've attached patches for bash-4.1 and bash-4.2. Please let me know if
> they fix the problem; they seem to fix it for me.
>
> Chet
Hel
On 4/17/11 6:28 AM, pi...@piumalab.org wrote:
>
> 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-redhat-linux-
Matthew Woehlke wrote:
> Why is [ 0 == 0 ] any more or less true than [ 0 -eq 0 ]?
>
> The problem seems to be that this line is missing from the function:
> local n ret1 ret2
You're right about that. The OP and I conversed via email and resolved
his questions.
Chet
--
``The lyf so short, th
(things I forgot to say the first time...)
Matthew Woehlke wrote:
Chet Ramey wrote:
seba wrote:
GNU bash, version 3.2.25(1)-release (i686-pc-linux-gnu)
Copyright (C) 2005 Free Software Foundation, Inc.
#!/bin/sh
This is wrong. You're using features that are not in classic Bourne
shell. This
Chet Ramey wrote:
seba wrote:
GNU bash, version 3.2.25(1)-release (i686-pc-linux-gnu)
Copyright (C) 2005 Free Software Foundation, Inc.
#!/bin/sh
fib() {
n=$1
[ $n == 0 -o $n == 1 ] && return $n
fib $(($n-1))
ret1=$?
fib $(($n-2))
ret2=$?
return
Chet Ramey wrote:
> seba wrote:
>> #!/bin/sh
>>
>> fib() {
> You managed to write yourself an infinitely-recursive function, and
> eventually ran out of stack space. `==' is a string operator, not a
> numeric operator, when used with `['.
Most likely. When I test this and it breaks, the stack h
seba wrote:
> GNU bash, version 3.2.25(1)-release (i686-pc-linux-gnu)
> Copyright (C) 2005 Free Software Foundation, Inc.
>
> #!/bin/sh
>
> fib() {
>n=$1
>[ $n == 0 -o $n == 1 ] && return $n
>fib $(($n-1))
>ret1=$?
>fib $(($n-2))
>ret2=$?
>r
Z the root wrote:
> Configuration Information [Automatically generated, do not change]:
> Machine: powerpc
> OS: aix4.3.2.0
> Compiler: cc
> Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='powerpc'
> -DCONF_OSTYPE='aix4.3.2.0' -DCONF_MACHTYPE='powerpc-ibm-aix4.3.2.0'
> -DCONF_VENDOR='ibm'
On Sun, Feb 19, 2006 at 09:12:20PM +, Dmitry A. Kharitonov wrote:
[...]
> Bash Version: 2.05b
[...]
> [EMAIL PROTECTED] user]$ bash bashbug.sh
> 1
> bashbug.sh: line 9: {SPEEDACCUM[block-1]}: syntax error: operand
> expected (error token is "{SPEEDACCUM[block-1]}")
> Segmentation fault
Thank
44 matches
Mail list logo
