On 7/24/23 11:58 AM, vc--- via Bug reports for the GNU Bourne Again SHell
wrote:
Bash Version: 5.2
Patch Level: 15
Release Status: release
Description:
Segmentation fault in 'for ((...))' loop
Repeat-By:
z='';for((;$z;));do echo;done
without spaces in ;$z;
in b
On 5/30/23 1:17 AM, Wiley Young wrote:
Hi,
While trying to capture line numbers in an array to print with the rest
of the shell's debugging info, a segfault ..
Wiley
Thanks for the report. This will be fixed in the next devel branch push.
--
``The lyf so short, the craft so l
On 4/21/23 1:15 PM, Grisha Levit wrote:
One more issue after the fix, the start can end up being further than pcomp_ind
Thanks for the follow up. We have to distinguish between lines with only
whitespace following any assignment statements and other non-empty lines.
Chet
--
``The lyf so shor
On Wed, Apr 19, 2023, 10:23 Chet Ramey wrote:
> On 4/18/23 6:15 PM, Grisha Levit wrote:
> > $ bash --rcfile <(echo 'complete -C: -I') -i <<<$'; \cA\t'
> > bash-5.2$ bash: xmalloc: cannot allocate 18446744073709551615 bytes
> > $ bash --rcfile <(echo 'complete -C: -I') -i <<<$';\cA \t'
> > bash-5.
On 4/18/23 6:15 PM, Grisha Levit wrote:
$ bash --rcfile <(echo 'complete -C: -I') -i <<<$'; \cA\t'
bash-5.2$ bash: xmalloc: cannot allocate 18446744073709551615 bytes
$ bash --rcfile <(echo 'complete -C: -I') -i <<<$';\cA \t'
bash-5.2$ Segmentation fault: 11
Thanks for the report.
--
``The l
On 3/27/23 12:49 PM, Grisha Levit wrote:
another size_t issue
Thanks for the reports.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
On 2/28/23 10:51 AM, Grisha Levit wrote:
history-search-* commands segfault on the devel branch since the size_t
changes
Thanks for the report. It's odd that I never ran into this when testing the
case-insensitive search changes.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chau
On 12/18/22 1:35 AM, Harald van Dijk wrote:
Bash Version: 5.2
Patch Level: 12
Release Status: release
Description:
bash segfaults if 'set -o emacs' is run when it is executing a command
string.
You might win the prize for oldest bug reported. This is easily over 30
years old. I suppose
On Sun, Dec 18, 2022 at 06:35:45AM +, Harald van Dijk wrote:
> The assumption here, that if (interactive), input is coming from
> stdin, does not hold when running bash -ic.
>
> Repeat-By:
> bash -ic 'set -o emacs'
Wow, this is a very old bug. I think this 2.04 bug report fr
On 7/14/20 12:02 PM, Ilkka Virta wrote:
> On 14.7. 16:08, Chet Ramey wrote:
>> On 7/14/20 6:32 AM, Jeffrey Walton wrote:
>>> ./audit-libs.sh: line 17: 22929 Segmentation fault (core dumped)
>>> $(echo "$file" | grep -E "*.so$")
>>
>> Bash is reporting that a process exited due to a seg fault,
On 14.7. 16:08, Chet Ramey wrote:
On 7/14/20 6:32 AM, Jeffrey Walton wrote:
./audit-libs.sh: line 17: 22929 Segmentation fault (core dumped)
$(echo "$file" | grep -E "*.so$")
Bash is reporting that a process exited due to a seg fault, but it is
not necessarily a bash process.
As a sugge
On 14.7. 13:32, Jeffrey Walton wrote:
Hi Everyone,
I'm working on a script to find all shared objects in a directory. A
filename should match the RE '*.so$'. I thought I would pipe it to
grep:
IFS="" find "$dir" -name '*.so' -print | while read -r file
do
if ! $(echo "$file" | grep -E "*
On 7/14/20 6:32 AM, Jeffrey Walton wrote:
> Hi Everyone,
>
> I'm working on a script to find all shared objects in a directory. A
> filename should match the RE '*.so$'. I thought I would pipe it to
> grep:
>
> $ ./audit-libs.sh /home/jwalton/tmp/ok2delete/lib
> ./audit-libs.sh: line 17: 22929 Se
> > IFS="" find "$dir" -name '*.so' -print | while read -r file
> > do
> > if ! $(echo "$file" | grep -E "*.so$"); then continue; fi
> > echo "library: $file"
> >
> > done
Also, I forgot to point out: your "if" line is executing each of
the shared libraries that you find. Every one of th
On Tue, Jul 14, 2020 at 06:32:44AM -0400, Jeffrey Walton wrote:
> $ ./audit-libs.sh /home/jwalton/tmp/ok2delete/lib
> ./audit-libs.sh: line 17: 22929 Segmentation fault (core dumped)
> $(echo "$file" | grep -E "*.so$")
This grep regular expression is not valid. The * symbol in a regular
expr
On 5/4/19 7:56 AM, Ole Tange wrote:
>> You've obviously overlooked the FUNCNEST variable and its effects,
>
> I tried with FUNCNEST:
>
> $ FUNCNEST=1
> $ re() { t=$((t+1)); if [[ $t -gt 800 ]]; then echo foo; return;
> fi; re; }; re
> Warning: Program '/bin/bash' crashed.
>
> So eve
On Fri, Apr 19, 2019 at 3:16 PM Chet Ramey wrote:
> On 4/19/19 4:21 AM, Ole Tange wrote:
> > Reading https://www.gnu.org/prep/standards/standards.html#Semantics
> >
> > """Avoid arbitrary limits on the length or number of any data
> > structure, including file names, lines, files, and symbols, by
On 4/19/19 4:21 AM, Ole Tange wrote:
>
> Reading https://www.gnu.org/prep/standards/standards.html#Semantics
>
> """Avoid arbitrary limits on the length or number of any data
> structure, including file names, lines, files, and symbols, by
> allocating all data structures dynamically."""
>
> Y
On 4/19/19 9:16 AM, Chet Ramey wrote:
> You've obviously overlooked the FUNCNAME variable
Sorry, `FUNCNEST' variable. Muscle memory.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.edu
On Fri, Apr 19, 2019 at 10:21:00AM +0200, Ole Tange wrote:
> Of course it is up to you, but if the current behaviour is a
> controlled exit working the way it was designed, I find it odd that
> there is no mention of it in the docs.
Functions may be recursive. The FUNCNEST variable may be
On Fri, Apr 12, 2019 at 7:18 PM Andrew Church wrote:
>
> >This recursive function causes bash to segfault:
> >
> >$ re() { t=$((t+1)); if [[ $t -gt 800 ]]; then echo foo; return;
> >fi; re; }; re
> >Segmentation fault (core dumped)
> >
> >Ideally Bash ought to run out of memory before this fai
On 4/12/19 12:12 PM, Andrew Church wrote:
>> This recursive function causes bash to segfault:
>>
>> $ re() { t=$((t+1)); if [[ $t -gt 800 ]]; then echo foo; return;
>> fi; re; }; re
>> Segmentation fault (core dumped)
>>
>> Ideally Bash ought to run out of memory before this fails. But an
>> ac
>This recursive function causes bash to segfault:
>
>$ re() { t=$((t+1)); if [[ $t -gt 800 ]]; then echo foo; return;
>fi; re; }; re
>Segmentation fault (core dumped)
>
>Ideally Bash ought to run out of memory before this fails. But an
>acceptable solution could also be to say 'stack overflow'.
On Mon, Oct 08, 2018 at 11:59:53 -0600, Bob Proulx wrote:
> Some of those must be maintaining the stack in program data space
> instead of in the machine stack space. (shrug)
Indeed. But as I mentioned in another comment, such an implementation
detail shouldn't matter to the user IMO.
> My inte
Mike Gerwitz wrote:
> Bob Proulx wrote:
> > Let me give the discussion this way and I think you will be
> > convinced. :-)
>
> Well, thanks for taking the time for such a long reply. :)
>
> > How is your example any different from a C program? Or Perl, Python,
> > Ruby, and so forth? All of tho
On Sun, Oct 07, 2018 at 09:42:01 +0700, Robert Elz wrote:
> I expect that if you did look, you'd probably find that while
> technically the former, it isn't a reference to some wild pointer,
> but rather simply growing the stack until the OS says "no more"
> and returns a SIGSEGV instead af allocat
On Sun, Oct 07, 2018 at 08:52:25 +0200, Valentin Bajrami wrote:
> As earlier expained, you are calling foo function recursively. To mitigate
> this behaviour you simple set FUNCNEST= foo() { foo; }; foo where N
> denotes the number of nested functios to be called.
This is perfect and clear behavio
Hi Mike,
As earlier expained, you are calling foo function recursively. To mitigate
this behaviour you simple set FUNCNEST= foo() { foo; }; foo where N
denotes the number of nested functios to be called.
Op zo 7 okt. 2018 07:57 schreef Mike Gerwitz :
> Hey, Bob!
>
> On Sat, Oct 06, 2018 at 22:4
Hey, Bob!
On Sat, Oct 06, 2018 at 22:44:17 -0600, Bob Proulx wrote:
> Let me give the discussion this way and I think you will be
> convinced. :-)
Well, thanks for taking the time for such a long reply. :)
> How is your example any different from a C program? Or Perl, Python,
> Ruby, and so for
Hi Mike,
Mike Gerwitz wrote:
> ... but are you saying that terminating with a segfault is the
> intended behavior for runaway recursion?
Let me give the discussion this way and I think you will be
convinced. :-)
How is your example any different from a C program? Or Perl, Python,
Ruby, and so f
Date:Sat, 06 Oct 2018 19:53:25 -0400
From:Mike Gerwitz
Message-ID: <874ldy1vka@gnu.org>
| I haven't inspected the code to see if this is an access
| violation or if Bash is intentionally signaling SIGSEGV.
I expect that if you did look, you'd probably find th
On Sat, Oct 06, 2018 at 12:33:22 -0400, Chet Ramey wrote:
> On 10/5/18 9:33 PM, Mike Gerwitz wrote:
>> The following code will cause a segfault on bash-4.4.19(1) on
>> GNU Guix. I reproduced the issue on an old Ubuntu 14.04 LTS running
>> bash-4.3.11(1) as well as a Trisquel system running the sam
On 10/5/18 9:33 PM, Mike Gerwitz wrote:
> The following code will cause a segfault on bash-4.4.19(1) on
> GNU Guix. I reproduced the issue on an old Ubuntu 14.04 LTS running
> bash-4.3.11(1) as well as a Trisquel system running the same version.
>
> bash -c 'trap "kill 0" TERM; kill 0'
>
> Als
I don't know if this makes consistency easier or harder, but there is
currently code to handle `declare' with -[iluc] early [1]. As a result, a
combination of localvar_inherit and the use of one of those options when
declaring a local variable allows (correctly or not) for associative arrays
to inh
On 7/29/18 10:26 PM, Grisha Levit wrote:
> Though my motivation in reporting this was to point out the segfault, I'm a
> bit confused by why compound assignment should be an error here.
>
>> Bash is consistent in defaulting to indexed array variables when you don't
>> specify -A and assign a value
On 7/25/18 5:37 PM, Grisha Levit wrote:
> shopt -s localvar_inherit
> declare -A var
> f() { declare var+=([0]=X); }; f
This will generate an error about attempting to inherit a value from an
incompatible type.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
Though my motivation in reporting this was to point out the segfault, I'm a
bit confused by why compound assignment should be an error here.
> Bash is consistent in defaulting to indexed array variables when you don't
> specify -A and assign a value using the compound assignment syntax.
Since loc
On 7/26/18 3:15 PM, Grisha Levit wrote:
> It seems that in general the array type is inherited just fine, there is an
> issue only in the case that:
>* the `A' attribute is inherited but not explicitly supplied
>* we are creating the local variable with the `declare' command
> (i.e. it
It seems that in general the array type is inherited just fine, there is an
issue only in the case that:
* the `A' attribute is inherited but not explicitly supplied
* we are creating the local variable with the `declare' command
(i.e. it is not already an existing local variable)
* w
On 7/25/18 5:37 PM, Grisha Levit wrote:
> shopt -s localvar_inherit
> declare -A var
> f() { declare var+=([0]=X); }; f
This should be an error due to mismatched array types. The local variable
is an indexed array; the global variable is an associative array (though
it is unset). You can't inheri
On 7/17/18 1:55 PM, Grisha Levit wrote:
> $ echo $BASH_VERSION
> 4.4.23(1)-release
> $ f() { declare -a a; declare -A a; declare -p a; }; f
> bash: declare: a: cannot convert indexed to associative array
> declare -aA a
> Segmentation fault: 11
>
> This behavior is still present in the devel branc
On Fri, Nov 10, 2017 at 2:19 PM, Eduardo A. Bustamante López
wrote:
> I think the fix looks something like this:
> + localconv = (iconv_t)-1; /* initialize */
I can confirm that the crash is gone with this fix.
Thanks a lot, Eduardo!
e.
On 11/10/17 8:19 AM, Eduardo A. Bustamante López wrote:
> On Fri, Nov 10, 2017 at 01:59:46PM +0100, Egmont Koblinger wrote:
> [...]
>> On Ubuntu Artful (glibc-2.26), this tiny snippet reproducibly crashes bash:
>>
>> LC_ALL=en_US.UTF-8 # or any other UTF-8 locale
>> echo -e '\ud800' # or
On Fri, Nov 10, 2017 at 01:59:46PM +0100, Egmont Koblinger wrote:
[...]
> On Ubuntu Artful (glibc-2.26), this tiny snippet reproducibly crashes bash:
>
> LC_ALL=en_US.UTF-8 # or any other UTF-8 locale
> echo -e '\ud800' # or any other lone high or low surrogate
> LC_ALL=en_US.UTF-8 #
On 10/6/17 6:58 PM, ANDERSON, CRAIG wrote:
> Repeat-By:
> Running the following script:
>
> #!/bin/bash
>
> exec >& >(while read line; do echo "$line"; done)
>
> trap 'echo sigpipe' SIGPIPE
> trap 'echo sigint' SIGINT
>
> echo 'Sleeping 60 seconds, press Ctrl+C to segfault!'
> sleep 60
On Mon, May 15, 2017 at 8:09 PM, Elliott Cable wrote:
> I'm no shell-script master, but this is segfaulting my Bash, and I was
> able to reproduce it on a couple different systems (including the #bash
> shbot :P):
>
> echo '_() { exec <&- ;}; _ "$0" "$@"' >bleh.sh
> cat bleh.sh | bash
It'
On 4/23/17 12:14 PM, Eduardo Bustamante wrote:
> I tried the following patch:
>
> dualbus@debian:~/src/gnu/bash$ git diff -- bashline.c
> diff --git a/bashline.c b/bashline.c
> index 129714aa..7884416a 100644
> --- a/bashline.c
> +++ b/bashline.c
> @@ -2545,7 +2545,7 @@ static void
> maybe_make_
On Sun, Apr 23, 2017 at 12:56 AM, Jaren Stangret wrote:
> Hello,
>
> Instead of segfaulting, BASH should ensure READELINE_LINE is unset or set
> and empty.
I am able to reproduce this with the latest devel branch. Here's the
stack trace:
Program received signal SIGSEGV, Segmentation fault.
0x000
On 4/4/17 7:54 PM, Grisha Levit wrote:
> Given:
>
> set -- $'\t'; IFS=$1 A=$1 # or set -- $'\n'
>
> These all segfault (in different places with -DDEBUG)
>
> : ${x-$@}
> [[ $@ ]]
> : ${x-${A[@]}}
> [[ ${A[@]} ]]
Thanks for the report. This was a little bit tricker to fix than I thought
it wo
On 11 Aug 2016 08:32, Chet Ramey wrote:
> On 8/11/16 8:29 AM, Mike Frysinger wrote:
> > simple code to reproduce:
> > bash -c 'v=$*'
>
> http://lists.gnu.org/archive/html/bug-bash/2016-07/msg00066.html
thanks ... still catching up after vacation and hadn't made it that far yet ;)
-mike
sign
On 8/11/16 8:29 AM, Mike Frysinger wrote:
> simple code to reproduce:
> bash -c 'v=$*'
http://lists.gnu.org/archive/html/bug-bash/2016-07/msg00066.html
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech
On 5/18/16 10:02 AM, Sarah Brofeldt wrote:
> I'm not sure whether this is actually acceptable behaviour, but a
> ridiculously long && chain blows up bash:
Bash will obediently attempt to run what you tell it to until it runs
out of resources.
--
``The lyf so short, the craft so long to lerne.''
On 4/27/16 2:45 AM, Grisha Levit wrote:
> Any of the following will crash bash:
>
> declare -n ref=a[*]; ref=
> declare -n ref=a[@]; ref=
> declare -n ref=a[-1]; a=(); ref=
>
> declare -A A; declare -n ref='A[$unset]'; ref=
>
> They all produce "bad array subscript" errors so could be caught.
T
Hi Grisha,
confirmed.
I think this one fixes it:
diff --git a/variables.c b/variables.c
index 69ed170..9eeda46 100644
--- a/variables.c
+++ b/variables.c
@@ -2636,9 +2636,14 @@ bind_variable_internal (name, value, table, hflags,
aflags)
#if defined (ARRAY_VARS)
/* declare -n foo=x[2] *
On 9/20/15 4:59 PM, r...@endoria.net wrote:
> When using HISTTIMEFORMAT and a timestamp which is out of range bash seems to
> segfault. I've tested this with bash version 4.3.30(1)-release
> (x86_64-pc-linux-gnu) on Debian 8 stable.
>
> Here is how to reproduce:
> * Change (or add) a timestamp i
On 9/19/15 12:22 PM, Brian Carpenter wrote:
> While fuzzing bash 4.4.0(1)-beta compiled from the devel branch, I found a
> 'script' that causes a segfault. The attached also crashes bash
> 4.2.37(1)-release. The file is 1012B in size and I was unable to minimize
> it any further using the afl-tmin
On 8/12/15 3:52 PM, isabella parakiss wrote:
> Bash segfaults when trying to do this: x=-3; echo ${!x}
> Here's the backtrace from gdb: https://gist.github.com/306f16a358527b267a1e
> It looks like the problem is the savestring macro when ind is negative.
Thanks for the report. This will be fixed
On 7/22/15 5:00 PM, Alexey Makhalov wrote:
> I have met situation when nfd(returned by fcntl) is 217, but nbuffers is
> only 25
>
> if (buffers[nfd])
> {
> /* What's this? A stray buffer without an associated open file
> descriptor? Free up the buffer and report the error. *
On 7/7/15 5:49 PM, Piotr Grzybowski wrote:
> hi,
>
> maybe I am mistaken, but I think that keeping track of the
> variables/functions bound/unbound by the loadable bultins leads to a
> complete hell of unmanageable code.
> It should be noted, that the builtins should clean by themselves,
> e.g.,
hi,
maybe I am mistaken, but I think that keeping track of the
variables/functions bound/unbound by the loadable bultins leads to a
complete hell of unmanageable code.
It should be noted, that the builtins should clean by themselves,
e.g., in this case mypid.c should contain something like:
int
On 9/5/14, 2:57 AM, bogun.dmit...@gmail.com wrote:
> This is more or less the way I am leaning. In the next version of bash,
> it
> will be possible to set a limit on the number of recursive source/. or
> eval
> calls at compile time. This will be accomplished by changing a define
2014-09-03 7:31 GMT-07:00 Chet Ramey :
> On 8/28/14, 2:02 PM, bogun.dmit...@gmail.com wrote:
> > IMHO any user action should not lead to SIGSEGV! I am not objecting
> against
> > recursive "sourse" itself. But when I got SIGSEGV from "bash", I have no
> > idea why this is happened. I have made rec
On 8/28/14, 2:02 PM, bogun.dmit...@gmail.com wrote:
> IMHO any user action should not lead to SIGSEGV! I am not objecting against
> recursive "sourse" itself. But when I got SIGSEGV from "bash", I have no
> idea why this is happened. I have made recursive "sourse" by mistake and
> spend a lot of ti
bogun.dmit...@gmail.com writes:
O... you have more serious bugs
Than fixing a segfault that occurs when the user is obviously doing
something stupid? Sure.
2014-08-28 15:44 GMT-07:00 Chris Down :
> bogun.dmit...@gmail.com writes:
>
>> And what for this mailing list? Don't answer, this have no any sense any
>> more.
>>
>
> This mailing list is for reporting bugs. So far nobody thinks that what
> you reported is a bug, so you would essentially be makin
bogun.dmit...@gmail.com writes:
And what for this mailing list? Don't answer, this have no any sense any
more.
This mailing list is for reporting bugs. So far nobody thinks that what
you reported is a bug, so you would essentially be making a feature
request. If you want to prioritise that, i
2014-08-28 15:32 GMT-07:00 Eric Blake :
> On 08/28/2014 04:11 PM, bogun.dmit...@gmail.com wrote:
> >> If gcc segfaults because it implements #include via recursion, and I
> >> wrote a recursion loop of #includes into my source, then I'd say the bug
> >> was mine, not gcc's. Just the same as if yo
On 08/28/2014 04:11 PM, bogun.dmit...@gmail.com wrote:
>> If gcc segfaults because it implements #include via recursion, and I
>> wrote a recursion loop of #includes into my source, then I'd say the bug
>> was mine, not gcc's. Just the same as if you write a recursion loop
>> into your bash progra
2014-08-28 15:11 GMT-07:00 Chris Down :
> bogun.dmit...@gmail.com writes:
>
>> Is it so heavy to check length of $BASH_SOURCE array?
>>
>
> Adding artificial barriers that don't actually solve the problem are
> "heavy" in terms of technical debt, even if not code.
>
Ok. Please remove FUNCNEST limi
bogun.dmit...@gmail.com writes:
Is it so heavy to check length of $BASH_SOURCE array?
Adding artificial barriers that don't actually solve the problem are
"heavy" in terms of technical debt, even if not code.
2014-08-28 14:57 GMT-07:00 Eric Blake :
> On 08/28/2014 03:50 PM, bogun.dmit...@gmail.com wrote:
> > Any action in my script should lead to SIGSEGV in interpreter! If I write
> > program on some compilable language, for example C, compile it and got
> > SIGSEGV - this is my problem. But in this ca
2014-08-28 14:43 GMT-07:00 Eric Blake :
> On 08/28/2014 03:00 PM, bogun.dmit...@gmail.com wrote:
> >>> Whey there is check on division by zero? We can predict this? - No. But
> >> we
> >>> can detect it... and we out nice, detailed error message.
> >>
> >> Actually, division by zero is fairly easy
On 08/28/2014 03:50 PM, bogun.dmit...@gmail.com wrote:
> Any action in my script should lead to SIGSEGV in interpreter! If I write
> program on some compilable language, for example C, compile it and got
> SIGSEGV - this is my problem. But in this case, my program executed by
> interpreter, and if
2014-08-28 13:59 GMT-07:00 Bob Proulx :
> bogun.dmit...@gmail.com wrote:
> > Eric Blake wrote:
> > > bogun.dmit...@gmail.com wrote:
> > > > IMHO any user action should not lead to SIGSEGV! I am not objecting
> against
> > > > recursive "sourse" itself. But when I got SIGSEGV from "bash", I
> have
On 08/28/2014 03:00 PM, bogun.dmit...@gmail.com wrote:
>>> Whey there is check on division by zero? We can predict this? - No. But
>> we
>>> can detect it... and we out nice, detailed error message.
>>
>> Actually, division by zero is fairly easy to check, and this is probably
>> a case where bash
2014-08-28 12:08 GMT-07:00 Eric Blake :
> On 08/28/2014 12:49 PM, bogun.dmit...@gmail.com wrote:
>
> > If follow this logic - we shoul try to catch incorrect user behaviour...
> we
> > will got errors/signals from kernel.
> >
> > Simple situation:
> > $ ((1/0))
> > bash: ((: 1/0: division by 0 (er
bogun.dmit...@gmail.com wrote:
> Eric Blake wrote:
> > bogun.dmit...@gmail.com wrote:
> > > IMHO any user action should not lead to SIGSEGV! I am not objecting
> > > against
> > > recursive "sourse" itself. But when I got SIGSEGV from "bash", I have no
> > > idea why this is happened. I have made
2014-08-28 11:54 GMT-07:00 Greg Wooledge :
> On Thu, Aug 28, 2014 at 11:49:02AM -0700, bogun.dmit...@gmail.com wrote:
> > So why I should got SIGSEGV instead of nice, detailed error message in
> > recursion? We can detect it?
>
> You can't detect that it's going to happen. You can only receive th
On 08/28/2014 12:49 PM, bogun.dmit...@gmail.com wrote:
> If follow this logic - we shoul try to catch incorrect user behaviour... we
> will got errors/signals from kernel.
>
> Simple situation:
> $ ((1/0))
> bash: ((: 1/0: division by 0 (error token is "0")
>
> Whey there is check on division by
On Thu, Aug 28, 2014 at 11:49:02AM -0700, bogun.dmit...@gmail.com wrote:
> So why I should got SIGSEGV instead of nice, detailed error message in
> recursion? We can detect it?
You can't detect that it's going to happen. You can only receive the
SIGSEGV *after* it happens.
We already have a conf
2014-08-28 11:30 GMT-07:00 Eric Blake :
> On 08/28/2014 12:02 PM, bogun.dmit...@gmail.com wrote:
> > IMHO any user action should not lead to SIGSEGV! I am not objecting
> against
> > recursive "sourse" itself. But when I got SIGSEGV from "bash", I have no
> > idea why this is happened. I have made
On 08/28/2014 12:02 PM, bogun.dmit...@gmail.com wrote:
> IMHO any user action should not lead to SIGSEGV! I am not objecting against
> recursive "sourse" itself. But when I got SIGSEGV from "bash", I have no
> idea why this is happened. I have made recursive "sourse" by mistake and
> spend a lot of
IMHO any user action should not lead to SIGSEGV! I am not objecting against
recursive "sourse" itself. But when I got SIGSEGV from "bash", I have no
idea why this is happened. I have made recursive "sourse" by mistake and
spend a lot of time looking up what exactly lead to SIGSEGV.
Put a configura
On 08/27/2014 07:07 PM, bogun.dmit...@gmail.com wrote:
>
> Expected result:
> Block "source" for files already listed in "${BASH_SOURCE}". Perhaps this
> behavior and "changed" behavior should be switched by option in "set"
> command.
No. Recursive sourcing is useful, don't prohibit it artificia
On Aug 28, 2014, at 12:37 PM, Chris Down wrote:
> I really don't understand -- why is this unexpected? It's exactly what I'd
> expect to happen if you try to do something like that. It should not be
> disallowed to source yourself, that prevents people from doing things when
> *sensibly* sourc
I really don't understand -- why is this unexpected? It's exactly what
I'd expect to happen if you try to do something like that. It should not
be disallowed to source yourself, that prevents people from doing things
when *sensibly* sourcing their own script.
On Wednesday, May 07, 2014 10:58:42 AM Chet Ramey wrote:
> On 5/7/14, 10:21 AM, Dan Douglas wrote:
> > Another one to do with namerefs. :-)
> >
> > Looks like it's when the target of the ref is local to the same scope.
> >
> > $ gdb -q -ex 'run -c "function f { typeset x; typeset -n x; x=y; }; f"
On 5/7/14, 10:21 AM, Dan Douglas wrote:
> Another one to do with namerefs. :-)
>
> Looks like it's when the target of the ref is local to the same scope.
>
> $ gdb -q -ex 'run -c "function f { typeset x; typeset -n x; x=y; }; f"' ./bash
Thanks for the report. This is an abstraction layer violat
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-ag
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 bre
On 8/22/12 7:28 AM, arman...@gmail.com wrote:
> Configuration Information [Automatically generated, do not change]:
> Machine: i686
> OS: linux-gnu
> Compiler: gcc
> Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686'
> -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-redhat-linux-gnu'
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 5/18/12 2:08 PM, Dan Douglas wrote:
> Hi Chet, segfault occurs during array assignment if an attempt is made to
> modify a
> variable of the same name from the environment. It appears to only occur in
> the global scope.
> I imagine the expected r
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/19/11 11:12 AM, Dan Douglas wrote:
> Hi, This seems to corrupt the array in a way that crashes when trying to
> expand the array. Also occurs with the previous patchset.
>
> ~ $ ( while read -rn 1 'x[y++]'; do :; done < <(printf '%s\n' {0..5});
On 09/15/2011 08:38 PM, Chet Ramey wrote:
Bash Version: 4.1
Patch Level: 5
Release Status: release
Description:
Accidentally found the bug. This is what I executed:
/bin/bash -c 'declare -r a[]=asd'
Thanks for the report. I'll take a look.
Chet
The crash is in builtins/declare.def o
> Bash Version: 4.1
> Patch Level: 5
> Release Status: release
>
> Description:
> Accidentally found the bug. This is what I executed:
> /bin/bash -c 'declare -r a[]=asd'
Thanks for the report. I'll take a look.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
95 matches
Mail list logo
