On 8/26/24 10:57 PM, Zachary Santer wrote:
Bash Version: 5.3
Patch Level: 0
Release Status: alpha
This is devel, commit 2e01122fe7.
Really don't get what's going on here:
You have two instances of the shell fighting over terminal input.
--
``The lyf so short, the craft so long to lerne.'' -
On 8/26/24 6:44 PM, youheng@gmail.com wrote:
Bash Version: 5.3
Patch Level: 0
Release Status: alpha
POC:
$ cat poc.sh
eval '<${;}'
The specific case is an empty command containing only a redirection that
results in an expansion error read from a script or string.
I can confirm that the
On 8/26/24 9:52 PM, Dale R. Worley wrote:
writes:
Repeat-By:
1. Create a script, i.e. `poc.sh` with the problematic string
2. Execute `bash poc.sh`
Interestingly, when I run it (bash 5.1.0(1), which is pretty old), I
don't get the seg fault when I enter that string from the
On Sun, Aug 25, 2024 at 8:57 PM wrote:
>
> All the following scripts can create a Segmentation Fault
>
> eval '<$[;]'
>
> eval '<$(;)'
>
> eval '<${;}'
>
> eval '<$[|]&#
writes:
> Repeat-By:
> 1. Create a script, i.e. `poc.sh` with the problematic string
> 2. Execute `bash poc.sh`
Interestingly, when I run it (bash 5.1.0(1), which is pretty old), I
don't get the seg fault when I enter that string from the keyboard, only
when it's read from a scrip
>> These still cause the current devel branch to segfault, but (at least
>> for me, on macOS) only when invoked via argument, as OP directed. For
>> example, reading the scripts via stdin avoids the segfault.
Tested on commit cf694865de527e597de5a906643a74037341a431
I reproduced within a Docker
can create a Segmentation Fault
eval '<$[;]'
eval '<${;}'
eval '<$[|]'
These still cause the current devel branch to segfault, but (at
least for me, on macOS) only when invoked via argument, as OP
directed. For example, reading th
On Sun, Aug 25, 2024, at 6:24 PM, youheng@gmail.com wrote:
> Bash Version: 5.1
>
> Patch Level: 16
Note that this version of bash is outdated and will not receive
further updates. The current release is 5.2.
> All the following scripts can create a Segmen
From: Youheng Lü
To: bug-bash@gnu.org
Subject: eval '<$(;)' causes Segmentation Fault
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -g -O2 -flto=auto -ffat-lto-objects -flto=auto
-ffa
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
sh/2019-07/msg4.html
Repeat-By:
The simplest case can be reproduced with the following steps:
foo () { sleep 10; echo 'output from long task'; }
bar_1 () { time foo; }
bar_1 # interrupt after a few seconds
bar_1 # Segmentation fault
inux mcgrath 3.13.0-117-generic #164~precise1-Ubuntu SMP Mon
Apr 10 16:16:25 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 5.1.16
Patch Level: 16
Release Status: release
Description:
Sometimes, Bash runs into segmentation-fault due to memory
mana
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
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
: 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 I'm not sure what is causing this seg faul
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)
b
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
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''
Hello,
Running the fc builtin on an empty history list results in a
segmentation fault from bash.
Additional info:
* Operating system: Arch Linux
* Architecture: x86_64
* bash version: 5.1.8(1)-release
Steps to reproduce:
$ bash --noprofile --norc
$ HISTCONTROL=ignorespace
$ history -c
: 8
Release Status: release
Description:
Running the fc builtin on an empty history list results in a
segmentation fault from bash.
Repeat-By:
Run the following commands and observe the output:
$ bash --noprofile --norc
$ HISTCONTROL=ignoresp
On 5/5/20 12:16 PM, Franklin, Jason wrote:
> Agreed. This is an undocumented feature, which is why Brandon and I had
> a bit of trouble figuring out what "should" happen. :/
>
>> I'm leaning towards making 0 and -0 out-of-range errors for the non-listing
>> case. This is what other shells do (th
On 5/5/20 11:41 AM, Chet Ramey wrote:
> Thanks for the report and your careful analysis.
>
>>
>> Allow me to explain the reasoning behind the patch...
>>
>> From the CHANGES file, we see this note concerning the "fc" builtin:
>>
>> b. The fc builtin now interprets -0 as the current command line
On 5/5/20 9:21 AM, Franklin, Jason wrote:
> Greetings:
>
> Yesterday, I encountered a segmentation fault when using the "fc"
> builtin command. I cloned the Bash source code from GNU Savannah, and I
> verified that the bug is still present in the latest commits to the
&g
Greetings:
After sending the original email concerning this issue, I delved into
the code again for one last review. I discovered that, even after the
original fix a segmentation fault is still possible, because histbeg
could be higher than histend! The idea from "fc" would be to prin
Greetings:
Yesterday, I encountered a segmentation fault when using the "fc"
builtin command. I cloned the Bash source code from GNU Savannah, and I
verified that the bug is still present in the latest commits to the
master and devel branches (the work below applies to "devel&q
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/
pc:/tmp/build-bash-devel$ make -j$(nproc)
> | (...)
> | dualbus@system76-pc:/tmp/build-bash-devel$ ./bash -c $'x=0; :
> ${x/#[0\xef\xbf\xbd\\Z[:]]}'
> | Segmentation fault (core dumped)
> I have been looking around but I don't understand what's going on. I can se
evel$ ./bash -c $'x=0; :
${x/#[0\xef\xbf\xbd\\Z[:]]}'
| Segmentation fault (core dumped)
Here's the stack trace:
| dualbus@system76-pc:/tmp/build-bash-devel$ gdb ./bash --args ./bash -c $'x=0;
: ${x/#[0\xef\xbf\xbd\\Z[:]]}'
| GNU gdb (Debian 8.2.1-2+b1) 8.2.1
| (.
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^[.^[^
8w9tEBADAQCR0wCTAwMDAwMP9cDwf/XA9xMHEbCQkJ
AADoAwUAMDAw9g==
debian@debian-fuzz:/mnt$ LC_ALL=zh_CN.gbk ~/build/bash --noprofile --norc -c
'PATH= read -e < rl_do_undo' >/dev/null 2>&1; echo $?
Segmentation fault
139
And the backtrace:
(gdb) bt
#0 0x55656672
< rl_change_case
8rGosQEbVQ==
debian@debian-fuzz:/mnt$ cat -A rl_change_case
M-rM-1M-(M-1^A^[U
I patched bash to remove the isatty() check for `read -e', and ran (with:
LC_ALL=zh_CN.gbk):
(...)
(gdb) r
Starting program: /home/debian/build-gdb/bash --noprofile --norc -c PATH=\
read\ -e\
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
from the beginning? (y or n) y
Starting program: /home/dualbus/src/gnu/bash/bash
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
bash-5.0$ ~"""""""""""&quo
> On 2018 Jul 20 , at 10:40 a, Mr Guiguilebreton wrote:
>
> Yes, i now. I test the syntax and the parse error because I programming a
> command interpreter bash in C language and I report the Segmentation Fault
> for help you to debug. If you want I can help you free to so
> On 2018 Jul 20 , at 9:27 a, Mr Guiguilebreton wrote:
>
> Hello, check this command in GNU bash, version 3.2.57(1)-release
> (x86_64-apple-darwin17):
>
> ls () { ls -lG;}; ls
You wrote a recursive function with no base case. Don't do that.
ls () { command ls -lG; }; ls
or use an alias
Hello, check this command in GNU bash, version 3.2.57(1)-release
(x86_64-apple-darwin17):
ls () { ls -lG;}; ls
freely,
Guillaume Madec
(+33)6 46 01 00 79
PS: It's a pleasure to help the FSF
On 3/19/18 4:52 AM, Koichi Murase wrote:
> Description:
>
> At the line lib/readline/bind.c:376, an uninitialized variable `ic'
> is used to assign a value to the variable `prevkey'. This assignment
> to `prevkey' should be later than the assignment to `ic'. This causes
> segmentation faults in
he following reduced case causing the
segmentation fault, but it should depend on environments because
accessing uninitialized variables generally results in undefined
behavior.
$ bash-5.0.0 --norc
$ bind -r '\C-j'
$ bind -r `\C-m`
Segmentation fault
Fix:
I attach a patch file
zzing.
>
> I think this might be similar to
> https://lists.gnu.org/archive/html/bug-bash/2017-05/msg00046.html
> (i.e. ``Segmentation fault in evalerror when xtrace and
> PS4='$[T[$]]'``)
>
> I think the fix *may* be something like:
You're on the right trac
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
>
")
Program received signal SIGSEGV, Segmentation fault.
strlen () at ../sysdeps/x86_64/strlen.S:106
106 ../sysdeps/x86_64/strlen.S: No such file or directory.
(gdb) bt
#0 strlen () at ../sysdeps/x86_64/strlen.S:106
#1 0x555b1ff7 in expassign () at expr.c:505
#2 0x
//9//5YE3pYUGxob3i8UlhQaVGbnJof/G4B7e/oGA1T/GxtTJAp5G/8aDBSUAAR7
/3t7e/oMFJQABHt7e3u/3hEUlhQbGxsq/4DtGxsbOBsfGxsE/+0F
Core was generated by `/home/dualbus/src/gnu/bash/bash -c read -e'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 strlen () at ../sysdeps/x86_64/strl
dualbus@debian:~/bash-fuzzing/read-readline$ base64 update_line 秧秧秧
MBs4MOenpzAwMDAwMDAwMBs4OOenpwESGQ==
Core was generated by `/home/dualbus/src/gnu/bash/bash -c read -e'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 __memcmp_sse4_1 () at ../sysdeps/x86_64/multiarch/m
kCnkb/xoMFJQABHv/e3t7+gwUlAAEe3t7e7/eERSWFBsbGyoAoRQCgAA2Gxs4
Gx8bGwT/7QU=
dualbus@afl-bash-history-fncm:~$ cat env
PATH=
VISUAL=:
EDITOR=:
bind -r "\C-x\C-e"
bind -q edit-and-execute-command
Core was generated by `/bash/bash -rc read -e'.
Program terminated with signal SIGSEGV, Segmentati
On 5/3/17 10:29 PM, Eduardo Bustamante wrote:
> 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:
It's all the same path.
--
``The lyf so short, the craft so long to lerne.
..
Starting program: /home/dualbus/src/gnu/bash/bash
bash-4.4$ read -e
0
Program received signal SIGSEGV, Segmentation fault.
strlen () at ../sysdeps/x86_64/strlen.S:106
106 ../sysdeps/x86_64/strlen.S: No such file or directory.
(gdb) bt
#0 strlen () at ../sysdeps/x86_64/strlen.S:106
#1
(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 "s
h/bash: -c: line 0: syntax error: `((;))'
Program received signal SIGSEGV, Segmentation fault.
0x55587a1c in yyparse () at ./parse.y:1151
1151 if ($1->type == cm_connection)
(gdb) bt
#0 0x55587a1c in yyparse () at ./parse.y:1151
#1 0x55584
tf '\n%s\n' ---; xxd "$f";
printf '%s\n' ---; bash -n "$f"; done
---
0 i[$($(0(){a[$(($(0)))}>))
---
: 3020 695b 2428 2428 3028 297b 615b 2428 0 i[$($(0(){a[$(
0010: 2824 2830 2929 297d 3e29 29 ($(0)))}>))
---
Segmentation fa
gdb) r -n ~/segfault
Starting program: /home/dualbus/src/gnu/bash/bash -n ~/segfault
Program received signal SIGSEGV, Segmentation fault.
strlen () at ../sysdeps/x86_64/strlen.S:137
137 ../sysdeps/x86_64/strlen.S: No such file or directory.
(gdb) bt
#0 strlen () at ../sysdeps/x86_64/strlen.S:
h:
<&-<${}
<&"-"<"$[~]"
<&"-"<"${}"
<&"-"<"${$0}"
<&"-"<$(())
But they are all triggered by the same bug. These were found by using
AFL: http://lcamtuf.coredump.cx/afl/
Repeat-By
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
>
Type: x86_64-unknown-linux-gnu
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 and versions, all of them
>>
>>> Description:
>>> popd controlled free (Segmentation fault) in all bash versions here
>>> around
>>
>> This has been fixed for a couple of weeks in the devel branch.
>
> can you cut a patch ?
Sure. It's not a security problem; it j
On 21 Nov 2016 10:13, Chet Ramey wrote:
> On 11/21/16 6:47 AM, wer...@suse.de wrote:
> > Bash Version: 4.2.47, 4.3.48, 4.4.5
> > Release Status: release
> > OpenSUSE bug: 1010845
> > CVE: 2016-9401
> >
> > Description:
> > popd controlled free (
On 11/21/16 6:47 AM, wer...@suse.de wrote:
> Bash Version: 4.2.47, 4.3.48, 4.4.5
> Release Status: release
> OpenSUSE bug: 1010845
> CVE: 2016-9401
>
> Description:
> popd controlled free (Segmentation fault) in all bash versions here
> around
This has been fixed
inux noether 4.1.34-33-default #1 SMP PREEMPT Thu Oct 20
08:03:29 UTC 2016 (fe18aba) x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-suse-linux-gnu
Bash Version: 4.2.47, 4.3.48, 4.4.5
Release Status: release
OpenSUSE bug: 1010845
CVE: 2016-9401
Description:
popd controlled free (Segmentat
On 3/11/16 9:25 AM, s...@kr41.net wrote:
> The following script cause Segmentation fault. I cleaned up the source, so
> removing any line "fixes" the problem.
Thanks for the report. This was fixed last August, and the fix was in
bash-4.4-beta.
--
``The lyf so short, the
The following script cause Segmentation fault. I cleaned up the source, so
removing any line "fixes" the problem.
$ ./sandbox.sh
Segmentation fault (core dumped)
$ cat sandbox.sh
#!/usr/bin/env bash
set -o errtrace
set -o functrace
SESSION="$( mktemp -d session.XXX
That's because of bash limiting the number of child processes to 1. ls
uses multiple threads, thus the crash.
On Wed, Mar 2, 2016 at 7:48 PM, Florian Mayer wrote:
> Hello,
>
> doing the following yields an segmentation fault.
> I am using bash 4.3.42(1) under Archlinux.
>
On 3/2/16 1:48 PM, Florian Mayer wrote:
> Hello,
>
> doing the following yields an segmentation fault.
> I am using bash 4.3.42(1) under Archlinux.
>
> /prlimit --nproc=1 bash//
> //[florian@kurerm ~]$ pwd//
> ///home/florian//
> //[florian@kurerm ~]$ ls//
>
Hello,
doing the following yields an segmentation fault.
I am using bash 4.3.42(1) under Archlinux.
/prlimit --nproc=1 bash//
//[florian@kurerm ~]$ pwd//
///home/florian//
//[florian@kurerm ~]$ ls//
//bash: fork: retry: No child processes//
//bash: fork: retry: No child processes//
//bash: fork
unning trap for signal 15
| ./bash: line 1: warning: run_pending_traps: recursive invocation while
running trap for signal 15
| zsh: segmentation fault ./bash -c 'trap "kill \$\$" TERM; kill $$'
Other shells that also segfault:
- dash:
| dualbus@hp ~/local/src/dash-0.5.8
> $ 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
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 is probably related to the bug patched by bash43-022.
On 6/19/14, 4:43 AM, scorp.dev.n...@gmail.com wrote:
> Bash Version: 4.2
> Patch Level: 45
> Release Status: release
>
> Description:
>
> in case use overwrite variables within "while loop" in lastpipe mode i get
> "Segmentation fault"
Thanks fo
0-12-generic #19-Ubuntu SMP Wed Oct 9 16:20:46
UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 4.2
Patch Level: 45
Release Status: release
Description:
in case use overwrite variables within "while loop" in lastpipe mode i get
"Segmentatio
On Thu, Feb 13, 2014 at 04:01:21PM -0500, Chet Ramey wrote:
> On 2/13/14 2:32 PM, Eduardo A. Bustamante López wrote:
> > On Thu, Feb 13, 2014 at 11:37:27AM -0500, Chet Ramey wrote:
> >> On 2/13/14 11:33 AM, Eduardo A. Bustamante López wrote:
> >>> Using an invalid byte sequence with printf %q segfa
On 2/13/14 2:32 PM, Eduardo A. Bustamante López wrote:
> On Thu, Feb 13, 2014 at 11:37:27AM -0500, Chet Ramey wrote:
>> On 2/13/14 11:33 AM, Eduardo A. Bustamante López wrote:
>>> Using an invalid byte sequence with printf %q segfaults bash, for a
>>> UTF-8 locale.
I think it depends on your syste
ons, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/dualbus/local/bin/bash...done.
(gdb) r ./printf-q
Starting program: /home/dualbus/local/bin/bash ./printf-q
Program received signal SIGSEGV, Segmentation fault.
0x004b4ba6 in ansic_quote (str=0x
On Thu, Feb 13, 2014 at 11:37:27AM -0500, Chet Ramey wrote:
> On 2/13/14 11:33 AM, Eduardo A. Bustamante López wrote:
> > Using an invalid byte sequence with printf %q segfaults bash, for a
> > UTF-8 locale.
>
> http://lists.gnu.org/archive/html/bug-bash/2014-02/msg00033.html
Thanks! I remember th
On 2/13/14 11:33 AM, Eduardo A. Bustamante López wrote:
> Using an invalid byte sequence with printf %q segfaults bash, for a
> UTF-8 locale.
http://lists.gnu.org/archive/html/bug-bash/2014-02/msg00033.html
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars lo
se see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/dualbus/local/bin/bash...done.
(gdb) r ./invalid-utf8
Starting program: /home/dualbus/local/bin/bash ./invalid-utf8
Program received signal SIGSEGV, Segmentation fault.
0x004b4bc0 in ansic_quote (str=0x7b0d68
On 2/6/14 10:25 PM, Dan Jacobson wrote:
>> "CR" == Chet Ramey writes:
>
> CR> OK, I'll bite. What is C-c C-c supposed to do? It looks like it just
> CR> spews a bunch of garbage to your screen. Is that the intent?
>
> C-c C-c runs the command comint-interrupt-subjob, which is an
> interac
Chet Ramey wrote:
> What is C-c C-c supposed to do?
It pretty much just sends SIGINT.
On 2014-02-06 22:16:56 -0500, Chet Ramey wrote:
> OK, I'll bite. What is C-c C-c supposed to do? It looks like it just
> spews a bunch of garbage to your screen. Is that the intent?
According to the Emacs manual[0]:
> Interrupt the shell or its current subjob if any
> (comint-interrupt-subjob)
> "CR" == Chet Ramey writes:
CR> OK, I'll bite. What is C-c C-c supposed to do? It looks like it just
CR> spews a bunch of garbage to your screen. Is that the intent?
C-c C-c runs the command comint-interrupt-subjob, which is an
interactive compiled Lisp function in `comint.el'.
(comint-
On 2/6/14, 6:11 PM, Dan Jacobson wrote:
> Dear Bug-Bash gentlemen,
> http://debbugs.gnu.org/16665 says it seems like a bash bug.
> Please have a look if you are also an emacs person.
OK, I'll bite. What is C-c C-c supposed to do? It looks like it just
spews a bunch of garbage to your screen. Is
Dear Bug-Bash gentlemen,
http://debbugs.gnu.org/16665 says it seems like a bash bug.
Please have a look if you are also an emacs person.
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=$
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
; 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 utf-8) sh -xc ': $N'
>> >
>> > Something abo
> $ sh /tmp/r
> > /tmp/r: line 1: 4551 Segmentation fault LC_CTYPE=zh_TW.UTF-8
> N=$(echo 統一|iconv -t big5 -f utf-8) sh -xc ': $N'
> >
> > Something about that embedded null.
> > bash, version 4.3.0(1)-rc1 (i486-pc-linux-gnu)
>
> Probably. How abo
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 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=$
# 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 utf-8) sh -xc ': $N'
Something
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
1 - 100 of 119 matches
Mail list logo
