Re: Segfault after many stackframes
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
> > allocating all data structures dynamically."""
> >
> > You could argue that Bash being a GNU tool, it should do like Perl:
> > Run out of memory before failing.
>
> 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 even by setting FUNCNEST it still crashes.
The man page 4.4.19(1) says:
"By default, no limit is imposed on the number of recursive calls."
which I cannot see as being correct. It may not be limited by
FUNCNEST, but it is clearly limited.
> I am curious about this point. Why do you think bash would exceed some
> kind of memory resource limit before it exceeds a stack 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 remember ever
seeing a program that segfaulted by design. All the segfaults I have
experienced were due to bugs in the program.
I imagine the segfault happens because we have a pointer outside the
stack size limit. Maybe just give an error and exit ("out of stack
space" or similar - preferably also telling me how to raise this limit
in case this was not an mistake), whenever such a pointer is
encountered instead of segfaulting? Had I seen that, I would not have
assumed it was a bug.
/Ole
Handling of Zero-Width escapes in PS1
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-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL
-DHAVE_CONFIG_H -I. -I../. -I.././include -I.././lib -Wdate-time
-D_FORTIFY_SOURCE=2 -g -O2 -fdebug-prefix-map=/build/bash-vEMnMR/bash-4.4.18=.
-fstack-protector-strong -Wformat -Werror=format-security -Wall
-Wno-parentheses -Wno-format-security
uname output: Linux desktop 5.0.3-050003-generic #201903191333 SMP Tue Mar 19
13:35:24 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 4.4
Patch Level: 19
Release Status: release
Description:
When setting up a complex PS1 prompt where parts of the
prompt is expanded on every new prompt displayed by bash
the escape sequences that are generated by that dynamic
part are handled improperly (read: not at all).
The desired behaviour should treat such escapes for e.g.
the sequences \[ and \] equal both when the prompt expands
to stuff\[stuff\]stuff, regardless of whether this was
reached by "stuff$(echo \[stuff\])stuff" (\[\] handled) or
reached by 'stuff$(echo \[stuff\])stuff' (not handled) being
set as the value of PS1.
Repeat-By:
To demonstrate this odd behaviour assume some command
that displays changing information at each invokation:
__test1(){ echo -e "Random is \\[\e[37;1m\\]$RANDOM\e[0m"; }
Now let's assume two cases:
Case 1:
PS1='Test$(__test1)Test\[\e[0m\]$ '
-> Shows \[\] markers, includes output of $(__test1) dynamically
Case 2:
PS1="Test$(__test1)Test\[\e[0m\]$ "
-> Displays correct, but statically includes output of $(__test1)
The desired behaviour is dynamic inclusion of $(__test1) as with
case 1 while having the \[\] markers respected as seen in case 2.
Splitting the output of __test1 to separate sections with
\[\] markers and such which don't need them is not possible,
as the number of such sections may vary and the limited syntax
of PS1 does not allow for loops and other conditional constructs
on its top level.
Also leaving out the \[\] markers from __test1 will cause the
displayed prompt to misbehave.
Fix:
Move handling of \[ and \] markers to be done on the fully
expanded, representation of the PS1 variable after variable
substitutions and subshell output have been inserted.
Re: Handling of Zero-Width escapes in PS1
On Sat, May 4, 2019, 3:39 PM 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-pc-linux-gnu'
> -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL
> -DHAVE_CONFIG_H -I. -I../. -I.././include -I.././lib -Wdate-time
> -D_FORTIFY_SOURCE=2 -g -O2
> -fdebug-prefix-map=/build/bash-vEMnMR/bash-4.4.18=.
> -fstack-protector-strong -Wformat -Werror=format-security -Wall
> -Wno-parentheses -Wno-format-security
> uname output: Linux desktop 5.0.3-050003-generic #201903191333 SMP Tue Mar
> 19 13:35:24 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
> Machine Type: x86_64-pc-linux-gnu
>
> Bash Version: 4.4
> Patch Level: 19
> Release Status: release
>
> Description:
> When setting up a complex PS1 prompt where parts of the
> prompt is expanded on every new prompt displayed by bash
> the escape sequences that are generated by that dynamic
> part are handled improperly (read: not at all).
>
> The desired behaviour should treat such escapes for e.g.
> the sequences \[ and \] equal both when the prompt expands
> to stuff\[stuff\]stuff, regardless of whether this was
> reached by "stuff$(echo \[stuff\])stuff" (\[\] handled) or
> reached by 'stuff$(echo \[stuff\])stuff' (not handled) being
> set as the value of PS1.
>
> Repeat-By:
> To demonstrate this odd behaviour assume some command
> that displays changing information at each invokation:
>
> __test1(){ echo -e "Random is \\[\e[37;1m\\]$RANDOM\e[0m"; }
>
> Now let's assume two cases:
>
> Case 1:
> PS1='Test$(__test1)Test\[\e[0m\]$ '
> -> Shows \[\] markers, includes output of $(__test1) dynamically
>
> Case 2:
> PS1="Test$(__test1)Test\[\e[0m\]$ "
> -> Displays correct, but statically includes output of $(__test1)
>
> The desired behaviour is dynamic inclusion of $(__test1) as with
> case 1 while having the \[\] markers respected as seen in case 2.
>
> Splitting the output of __test1 to separate sections with
> \[\] markers and such which don't need them is not possible,
> as the number of such sections may vary and the limited syntax
> of PS1 does not allow for loops and other conditional constructs
> on its top level.
>
> Also leaving out the \[\] markers from __test1 will cause the
> displayed prompt to misbehave.
>
> Fix:
> Move handling of \[ and \] markers to be done on the fully
> expanded, representation of the PS1 variable after variable
> substitutions and subshell output have been inserted.
>
I compute complex strings and assign PS1 within PROMPT_COMMAND rather than
expecting PS1's promptvars command substitution to do that - since
backslash escapes are done earlier. See "PROMPTING" in the man page where
the order of processing is described.
>
>
