On 8/30/24 5:05 AM, Eduardo A. Bustamante López wrote:
On Wed, Aug 28, 2024 at 01:16:57PM +0200, Tycho Kirchner wrote:
Hi,
Sending rapid SIGINTs from another shell quickly results in a SEGFAULT of the
bash instance receiving them. Steps to reproduce:
* Open up a shell SHELL_1 and record its
On 8/28/24 7:16 AM, Tycho Kirchner wrote:
Hi,
Sending rapid SIGINTs from another shell quickly results in a SEGFAULT of
the bash instance receiving them. Steps to reproduce:
* Open up a shell SHELL_1 and record its pid, e.g. "echo $$"
* Launch another shell and send rapid SIGINTs:
On 8/28/24 7:16 AM, Tycho Kirchner wrote:
Hi,
Sending rapid SIGINTs from another shell quickly results in a SEGFAULT of
the bash instance receiving them. Steps to reproduce:
* Open up a shell SHELL_1 and record its pid, e.g. "echo $$"
* Launch another shell and send rapid SIGINTs:
On Wed, Aug 28, 2024 at 01:16:57PM +0200, Tycho Kirchner wrote:
> Hi,
> Sending rapid SIGINTs from another shell quickly results in a SEGFAULT of the
> bash instance receiving them. Steps to reproduce:
> * Open up a shell SHELL_1 and record its pid, e.g. "echo $$"
> *
Hi,
Sending rapid SIGINTs from another shell quickly results in a SEGFAULT of the
bash instance receiving them. Steps to reproduce:
* Open up a shell SHELL_1 and record its pid, e.g. "echo $$"
* Launch another shell and send rapid SIGINTs: while true ; do kill -INT
OTHER_PID; don
On 11/28/23 11:16 AM, ra...@c.mail.sonic.net wrote:
Bash crashes with a segfault, unless the variable LC_CTYPE or LC_ALL
are set to a valid value (I have tried C, C.UTF-8, and en_US.UTF-8),
before any "other" commands are executed.
This was fixed by patch
FreeBSD 12.3-RELEASE-p6, on both architectures i386 and
amd64. Problem started after upgrading bash. Using packages, not built
from ports.
Bash crashes with a segfault, unless the variable LC_CTYPE or LC_ALL
are set to a valid value (I have tried C, C.UTF-8, and en_US.UTF
On Sun, Nov 19, 2023 at 10:31:59AM +0700, Robert Elz wrote:
> | $ history -c; fc -0
> | Segmentation fault (core dumped)
> |
> | Can someone else confirm this?
>
> Which bash version are you using?
>
> I just tried that on
> GNU bash, version 5.2.21(1)-release (x86_64--netbsd)
>
Date:Sat, 18 Nov 2023 21:55:23 -0500
From:Jason Franklin
Message-ID:
| $ history -c; fc -0
| Segmentation fault (core dumped)
|
| Can someone else confirm this?
Which bash version are you using?
I just tried that on
GNU bash, version 5.2.21(1)-r
Greetings:
I recall reporting a long time ago that "fc -0" would cause a segfault.
It appears that this behavior remains when the history is cleared prior
to invoking the "fc -0" command...
$ history -c; fc -0
Segmentation fault (core dumped)
Can someone else
On 9/8/23 12:36 PM, Grisha Levit wrote:
Since the change that made `test -t FD' report an error for non-numeric
values of FD:
$ [[ -t X ]]
bash: [[: X: integer expected
Segmentation fault
Thanks for the report and patch.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
_node code -- so the above now has an exit status of 2 like the test
builtin.
From 6e5be14727843d441f7c69a6e49473eabf049a9a Mon Sep 17 00:00:00 2001
From: Grisha Levit
Date: Fri, 8 Sep 2023 11:10:16 -0400
Subject: [PATCH] fix [[ -t X ]] segfault
Since the change that made `test -t FD' report an
On 7/25/23 5:31 AM, Dr. Werner Fink wrote:
Thanks for the report. This was fixed several months ago.
OK ... last official patch for 5.2 is still bash52-015 :)
https://lists.gnu.org/archive/html/help-bash/2023-07/msg00078.html
But the patch is simple enough to attach.
--
``The lyf so short,
On 2023/07/24 13:16:23 -0400, Chet Ramey wrote:
> 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:
>
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
Configuration Information [Automatically generated, do not change]:
Machine: amd64
OS: freebsd13.1
Compiler: cc
Compilation CFLAGS: -O2 -pipe -DLIBICONV_PLUG -fstack-protector-strong
-isystem /usr/local/include -fno-strict-aliasing
uname output: FreeBSD delta.hostmaster.ua 13.1-RELEASE-p5 FreeBS
On 6/16/23 1:02 AM, Wiley Young wrote:
Bash Version: 5.2
Patch Level: 15
Release Status: release
Description:
`verb=(--) declare -ax verb` causes bash to crash and closes the active
terminal tab. strace output includes this error: "getpeername(0,
0x7ffc74d185d0, [16])= -1 ENOTSOCK (Sock
On Fri, Jun 16, 2023 at 10:59:24AM -0400, Lawrence Velázquez wrote:
> % /bin/bash -c 'foo= declare -ax foo'
> zsh: segmentation fault /bin/bash -c 'foo= declare -ax foo'
>
> I am seeing this behavior with bash 3.2.57, so it appears to be
> longstanding.
On Fri, Jun 16, 2023, at 1:02 AM, Wiley Young wrote:
> Description:
>`verb=(--) declare -ax verb` causes bash to crash and closes the active
> terminal tab.
The value "(--)" does not seem to be necessary:
% /bin/bash -c 'foo= declare -ax foo'
zsh: segmentation fault /bin/bash -c 'foo= declar
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -O2 -flto=auto -ffat-lto-objects -fexceptions -g
-grecord-gcc-switches -pipe -Wall -Werror=format-security
-Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASS
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 cra
Hi,
While trying to capture line numbers in an array to print with the rest
of the shell's debugging info, a segfault ..
Wiley
[liveuser@localhost-live]$ bash
...
$ set -x
+ set -x
$ echo $SHLVL
+ echo 2
2
$ declare -n n=BASH_SOURCE; declare -n e=LINENO; shopt -s expand_al
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
$ 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
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/
another size_t issue
diff --git a/bashline.c b/bashline.c
index 0047caef..9df26d2e 100644
--- a/bashline.c
+++ b/bashline.c
@@ -919,7 +919,7 @@ hostnames_matching (const char *text)
continue;
/* OK, it matches. Add it to the list. */
- if (nmatch >= (rsize - 1))
+ if ((n
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
history-search-* commands segfault on the devel branch since the size_t
changes
---
lib/readline/search.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/readline/search.c b/lib/readline/search.c
index b7be876f..525c9c69 100644
--- a/lib/readline/search.c
+++ b/lib
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
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnux32
Compiler: clang -mx32
Compilation CFLAGS: -O2
uname output: Linux framework 6.0.12 #1 SMP PREEMPT_DYNAMIC @1664744947 x86_64
GNU/Linux
Machine Type: x86_64-pc-linux-gnux32
Bash Version: 5.2
Patch
On 9/30/22 6:41 AM, Emanuele Torre wrote:
On 30/09/2022, Emanuele Torre wrote:
In bash-5.2, using the ${parameter@Q} parameter expansion with an unset
parameter, in an array subscript, in an arithmetic context, causes a
segmentation fault.
Actually, using any parameter expansion with an unset
On 30/09/2022, Emanuele Torre wrote:
> In bash-5.2, using the ${parameter@Q} parameter expansion with an unset
> parameter, in an array subscript, in an arithmetic context, causes a
> segmentation fault.
Actually, using any parameter expansion with an unset parameter in an
array subscript causes
ut of bounds, hence the segfault.
That's backwards. You got a SIGSEGV, but it doesn't mean you forced bash to
write beyond its address space. You get SIGSEGV when you exceed your stack
or VM resource limits. Given the nature of the original script, it's
probably the former.
I am not
; I did force it to write out of bounds, hence the segfault.
>
> That's backwards. You got a SIGSEGV, but it doesn't mean you forced bash to
> write beyond its address space. You get SIGSEGV when you exceed your stack
> or VM resource limits. Given the nature of the original scrip
On 6/7/22 7:57 AM, Gergely wrote:
>> Because you haven't forced bash to write outside its own address space or
>> corrupt another area on the stack. This is a resource exhaustion issue,
>> no more.
>
>
> I did force it to write out of bounds, hence the segfau
t though and bash has no
>> control over what happens should this occur.
>
> Because you haven't forced bash to write outside its own address space or
> corrupt another area on the stack. This is a resource exhaustion issue,
> no more.
I did force it to write out of bounds, hen
people request. But it's
there if you (or a distro) want to build it in.
Speaking for myself, I'd find an error a much MUCH more palatable
condition than a segfault in this case. In the case of an error I at
least have a chance to do cleanup or emit a message, as opposed to just
termina
On 6/1/22 4:49 PM, Gergely wrote:
Hi,
I stumbled upon a recursion overflow crash in BASH. It affects both my
Debian machine (this report), as well as the latest stable built from
source.
Yes, you created an infinitely recursive script. It's a race to see whether
you exceed your stack or VM re
On 2022-06-02 at 20:00 +, Gergely wrote:
> Well, the issue is not the fact that this is a resource exhaustion,
> but rather the fact that it's entirely OS-dependent and the
> programmer has zero control over it.
The programmer could have avoided creating an infinite source file
recursion.
I d
On Jun 03 2022, Anna (cybertailor) Vyalkova wrote:
> 1. export CPPFLAGS="-DSYS_BASHRC='/home/sysrq/bash2/etc/bash/bashrc'"
SYS_BASHRC must be a string, not a multi-character constant.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: openbsd6.8
Compiler: tested with GCC and Clang
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='openbsd6.8' -DCONF_MACHTYPE='x86_64-pc-openbsd6.8'
-DCONF_VENDOR='pc' -DLOCALEDIR='/
like this, but there
is no knob to turn to prevent an abrupt termination, unlike FUNCNEST.
Speaking for myself, I'd find an error a much MUCH more palatable
condition than a segfault in this case. In the case of an error I at
least have a chance to do cleanup or emit a message, as opposed to j
Hi Gergely!
> I stumbled upon a recursion overflow crash in BASH.
There are many ways to exhaust memory (and other) recources, recursion is one
them. In your case a variable like SRCNEST (and all the code with its
performance impacts needed behind it) might help, but what exactly is the
advant
Level: 16
Release Status: release
Description:
A file repeatedly sourcing itself crashes bash with a segfault.
I did not have time to investigate, but it is alarming to me that
bash with some depths can survive the recursion, only to crash when I
try to run programs. This suggests to me
Hi,
> Yes. If you recurse indefinitely, you will eventually exceed your
> stack size resource limit and get the prescribed fatal signal.
Thanks for your answer, Chet. I understand how and why that happens in C
programs. However, I wasn't expecting that from a higher-level,
interpreted language
latest bash version (5.2.0(1)-beta).
Yes. If you recurse indefinitely, you will eventually exceed your stack
size resource limit and get the prescribed fatal signal.
Description:
Infinite recursion causes bash to segfault.
The problem happens in interactive mode as well as in
to segfault.
The problem happens in interactive mode as well as in scripts.
Repeat-By:
~$ bash
~$ foo () { foo; }; foo
Segmentation fault (core dumped)
~$
--
Judicaël Courant
Software Engineer, TrustInSoft
(+33) (0)6 52 42 88 23
https://trust-in-soft.com
On 10/6/21 10:47 PM, Koichi Murase wrote:
I'd like the default behavior to be closer to what it is when
assoc_expand_once is enabled, as I said back in March. I think it's
going to be better for users in the long run.
Does that mean the behavior with `assoc_expand_once' being disabled
also modi
> I'd like the default behavior to be closer to what it is when
> assoc_expand_once is enabled, as I said back in March. I think it's
> going to be better for users in the long run.
Does that mean the behavior with `assoc_expand_once' being disabled
also modified in a way incompatible with older B
On 10/5/21 10:39 PM, Koichi Murase wrote:
>> You're right, there should be no `nesting' considered at all. By the time
>> unbind_array_element is called, since it's only called from unset_builtin,
>> the word and subscript should have already undergone all the expansion
>> they're going to. There
> The difference is that valid_array_reference can be called before
> any of the subscript is expanded, in which case you need to parse
> things that can be expanded, where unbind_array_element is called
> after all the expansions are performed (but see below).
>
> So let's see if we can talk throu
On 10/5/21 7:05 AM, Koichi Murase wrote:
> The segmentation fault is fixed by the above patch, but there
> still remains the same error as bash 4.4.
>
> bash-patch1: ${x[0: bad substitution
>
> This is caused by an inconsistency between `valid_array_reference
> (name,flags)' (arrayfu
> In Bash 4.0--5.3, the unset command causes the following error:
>
> bash-4.0: [${x[0]}]: bad array subscript
Sorry, please ignore these two lines. This part is unrelated to the
fix of the patches. The above error message was produced for the empty
associative array key, which is the expect
(even when VA_NOEXPAND is not specified). I believe the former code
should be the expected one.
* In the second patch `0002-patch', the subscript extraction in
`unbind_array_element' is adjusted to match with that of
`valid_array_element'.
--
Koichi
0001-fix-unset-segfault-on-assoc-subscripts-with-paramexp.patch
Description: Binary data
0002-allow-nesting-and-quoting-in-assoc-subscripts-when-a.patch
Description: Binary data
On 8/30/20 9:36 PM, Koichi Murase wrote:
> Bash Version: 5.1
> Patch Level: 0
> Release Status: release
>
> Description:
>
> In the devel branch (e4d38c2d: commit bash-20200819 snapshot), a
> segmentation fault occurs when a prompt command stored in the array
> version of PROMPT_COMMAND un
2020-08-31 10:36 Koichi Murase :
> Description:
>
> In the devel branch (e4d38c2d: commit bash-20200819 snapshot), a
> segmentation fault occurs when a prompt command stored in the array
> version of PROMPT_COMMAND unsets the corresponding element in
> PROMPT_COMMAND.
I'm sorry, but I forg
Hi, I hit a segmentation fault with the array PROMPT_COMMAND. Here is
the report and a patch. There is also another trivial patch.
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -march=native -O3
uname output: Li
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 "*
s.sh: line 17: 22939 Segmentation fault (core dumped)
> $(echo "$file" | grep -E "*.so$")
> ...
>
> My code is broken at the moment. I know I am the cause of Bash's
> crash. But I feel like Bash should not segfault.
Bash is reporting that a process exited due to a seg
point out: your "if" line is executing each of
the shared libraries that you find. Every one of them matches the
grep check, and since you enclosed the check in a command substitution,
the output of grep (which is the pathname) is *executed* as a command.
That's probably where your s
lines that end
with the string ".so", it would be:
grep '\.so$'
However, the *use* of grep here is also incorrect.
> My code is broken at the moment. I know I am the cause of Bash's
> crash. But I feel like Bash should not segfault.
>
> IFS="" fin
...
My code is broken at the moment. I know I am the cause of Bash's
crash. But I feel like Bash should not segfault.
IFS="" find "$dir" -name '*.so' -print | while read -r file
do
if ! $(echo "$file" | grep -E "*.so$"); then continue; fi
echo "library: $file"
done
Are you guys interested in the segfault?
: x86_64-pc-linux-gnu
Bash Version: 5.0
Patch Level: 16
Release Status: release
Description:
Trying to tab expand a tilde causes segfault. This action requires us to
get user entries by calling getpwent which is provided by
libnss_systemd.so
on my system.
If we compile bash with it&#
On 6/21/19 3:22 PM, k...@plushkava.net wrote:
> Hi,
>
> The following script generates a compound command consisting of many
> instances of the : command. I have found that it reproducibly induces a
> segfault in all versions of bash from 2 onwards. I tested various other
>
Hi,
The following script generates a compound command consisting of many instances
of the : command. I have found that it reproducibly induces a segfault in all
versions of bash from 2 onwards. I tested various other shells - several more
than are implied here - all of which could handle the
hat I have reached the limit of recursion (like
> Zsh/Ksh) or by running out of memory (like Perl). I expect this to
> happen without setting FUNCNEST.
I can't understand why you think this is an answer to that question.
In any event, it would be appropriate for some distribution to
k size limit?
I expect bash to behave similar to other interpreted languages by
either telling me that I have reached the limit of recursion (like
Zsh/Ksh) or by running out of memory (like Perl). I expect this to
happen without setting FUNCNEST.
I do not expect bash to segfault ever, and I cannot
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)
> >
> >Ideall
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 r
>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 b
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 ove
le SIGSEGV and output a user-friendly message or do something
like FUNCNEST does today. libunwind wouldn't be necessary, but I
don't know enough about it to say whether or not it may be useful.
But seeing as how the segfault isn't a bug after all (I'd consider it a
lack o
gt; > Ruby, and so forth? All of those also allow infinite recursion and
> > the kernel will terminate them with a segfault. Because all of those
> > also allow infinite recursion. A program that executes an infinite
> > recursion would use infinite stack space. But real ma
and returns a SIGSEGV instead af allocating a new stack page.
That makes sense. Thanks.
Though, it is an implementation detail that IMO a user of bash shouldn't
have to worry about---if bash instead implemented its interpreter stack
on the heap rather than the same stack as bash itself, a segfault
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
gt; Ruby, and so forth? All of those also allow infinite recursion and
> > the kernel will terminate them with a segfault. Because all of those
> > also allow infinite recursion. A program that executes an infinite
> > recursion would use infinite stack space. But real machines h
Ruby, and so forth? All of those also allow infinite recursion and
> the kernel will terminate them with a segfault. Because all of those
> also allow infinite recursion. A program that executes an infinite
> recursion would use infinite stack space. But real machines have a
> finite a
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,
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 Trisqu
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 &
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'
Also segfaults when replacin
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
&
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 assignmen
If `var' is declared but not set, performing an @A or @a
transformation on double-quoted `var[@]' or `var[*]' will trigger a
segfault in dequote_string.
This is present in 4.4 and devel.
bash -c 'declare var; echo "${var[@]@A}"'
Segmentation fault: 11
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
shopt -s localvar_inherit
declare -A var
f() { declare var+=([0]=X); }; f
Segmentation fault: 11
* thread #1, stop reason = signal SIGSTOP
* frame #0: 0x000107abb72f bash`hash_search + 47
frame #1: 0x000107ac7324 bash`assoc_insert + 36
frame #2: 0x000107ac6658 bash`assign_co
Thanks for taking the time to explain that :) I'll do more homework next
time
On Sat, Jul 21, 2018, 8:51 PM Chet Ramey wrote:
> On 7/21/18 9:16 PM, Chris Schoenberg wrote:
> > Fair enough. Even though the behavior is different, the end is the same
> as
> > udf so makes sense of you want to leave
1 - 100 of 282 matches
Mail list logo
