Re: bash core dumps doing glob pattern on long string
On Tue, Oct 11, 2022 at 7:23 AM Martin D Kealey
wrote:
>
> 4) compile globs into state machines, the same way that regexes get
> compiled, so that they can be matched without needing any recursion.
>
> -Martin
>
Do you mean the NFA colud trade recursion for malloc()'d backtracking point
record? this would trade stacksize vs bss size. Or may be you mean
converting the NFA into DFA, that I could not handle myself :)
That's why at first I thought limiting the input string length was may be
an option, but Chet demonstrated it was not.
Then returning an error instead of core dumps on recursion too deep on the
NFA walk seems to be the thing to do, and then I thought a stack
availabitly check for a given recursive level could be done, this is pretty
easy to do and almost costless regarding perf, specially because bash (and
other shells) have access to alloca(), well we could admit that os/arch
sans alloca() could still core dump.
A stack check with alloca() ressemble something along this lines
int stack_too_small(size_t s)
{ return alloca(s)!=NULL;
}
This non inlinable function do allocate the stack provision, return true if
not possible, false if possible and return the provision to the stack, the
caller is then assured there is enough space in the stack for its recursion
frame.
and the shell code would look like
... recursive_func(...)
{...
if(stack_too_small(recursion_frame_size)
{ handle nicely; // longjmp, return
}
What Chet call the right size to define is possibly something like the
recursion frame size, that is the stack needed by the current recursion
level instance (its locals) + all the frame size sub function would need
until the next recurence, i.e if the call path look like
a()-->b()-->c()-->a()...
The recursion frame size is sum(framesize(a)+framesize(b)+framesize(c))
Some empiric constant can also be used, for instance on linux a max
stacksize of 0x80 is pretty common deciding we big constant like
32K could be simple and good enough.
Re: bash core dumps doing glob pattern on long string
On Mon, Oct 10, 2022 at 9:08 PM Chet Ramey wrote: > That's not the point. The point is that shell pattern matching is used in > contexts other than filename globbing, and the shell shouldn't broadly > impose a filename-only restriction on those uses. > > Chet > Ok got it, I was confused because the manual occurences of the term GLOB in bash doc seems to appears only in the "Pathname Expansion" paragraph, which point to a sub-paragraph called "Pattern Matching" so it looked to me like if "Pattern Matching" applied to "Pathname Expansion" Inside "Pattern Matching" we see ref to things like glob-complete-word (glob-* :-) ) all apply to "pattern for pathname expansion" extglob If set, the extended pattern matching features described above under Pathname Expansion are enabled. nocaseglob If set, bash matches filename... So at the point I thought that globbing was kind of related to the max file path of an OS. On the contrary I see nor reference saying the 'pattern matching for pathname expansion can also be used by extension to any strings, but now I understand it is. Yet let me know the strategy or limit you choose, and I will do the same for ksh93 Cheers,
Re: bash core dumps doing glob pattern on long string
On Sun, 9 Oct 2022 at 18:07, Phi Debian wrote: > I was looking at a bug on ksh93 that is "core dumps doing glob pattern on > long string" and it happen that bash > suffer the same. > > $ [[ $(printf '%010d' 0) == +(0) ]] > > I see 3 way of fixing this > > 1) [...] string should be limited to PATH_MAX [...] > 2) [...] have a fix recursion deep level [...] > 3) [...] Implement a stack deep check in the recursion [...] 4) compile globs into state machines, the same way that regexes get compiled, so that they can be matched without needing any recursion. -Martin
Re: bash core dumps doing glob pattern on long string
On 10/10/22 12:59 PM, Phi Debian wrote: Ok, I agry that PATH_MAX should not be considered, because not defined every where (OS's) That's not the point. The point is that shell pattern matching is used in contexts other than filename globbing, and the shell shouldn't broadly impose a filename-only restriction on those uses. Chet -- ``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/
Re: Less detailed error for ENOENT from execve
On 10/9/22 11:32 AM, Kirill Elagin wrote: Hi, I think the execute_cmd.c change here (https://git.savannah.gnu.org/cgit/bash.git/commit/?h=devel=1fff64acdc5709cdc213f0143f1b8169fdf68a39) made things worse, not better. I don’t know what the original report that prompted this change was though, but my impression is that the error became much less detailed. I see what you mean. The function should check for the interpreter case before printing the generic ENOENT message. I'll make that change. -- ``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/
Re: bash core dumps doing glob pattern on long string
Ok, I agry that PATH_MAX should not be considered, because not defined every where (OS's) If you decide a limit let me know I would use the same for ksh93 :) for the time being we core dump :) Cheers.
Re: New instances of Bash should ignore and reset BASH_ARGV0
On 10/10/22 2:38 AM, konsolebox wrote: This doesn't look right to me: # export BASH_ARGV0=fdsafasfas # bash # echo "$BASH_ARGV0|$0" fdsafasfas|fdsafasfas It's fine. If someone wants to set $0 when the shell starts, this is a way to do it. I added this back in 2019 as the result of a user request (which I can't find right now, naturally). -- ``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/
Re: bash core dumps doing glob pattern on long string
On 10/9/22 4:07 AM, Phi Debian wrote: I was looking at a bug on ksh93 that is "core dumps doing glob pattern on long string" and it happen that bash suffer the same. $ [[ $(printf '%010d' 0) == +(0) ]] I see 3 way of fixing this 1) [[ string == pattern ]] is for glob pattern, so string should be limited to PATH_MAX, so an upfront string length on string could prevent to call the glob pattern recursive functions, and then avoid the core dump. This isn't a valid assumption -- the conditional command is not solely for filename matching, as this example shows -- so not a good general solution. In fact, PATH_MAX shouldn't be considered at all. 2) Since some may have abused the glob pattern with long string bigger then PATH_MAX but smaller than core dump, imposing a PATH_MAX limit may break some wrong scripts, so instead we could have a fix recursion deep level, as we do have for shell functions calling, this hopefully should allow wrong doing script with abused string length to continue to run, yet avoiding core dump when reaching the limit, i.e break the call path. 3) Implement a stack deep check in the recursion, when getting close to the end of stack break the function trail (like function too deep for recursive functions). These are the same thing. You'd have to have a user-settable glob recursion limit, which is something that few people would understand and even fewer would set, since there's no good portable way to find how close you are to exceeding your stack size resource limit without exceeding it, and a simple string length check is not necessarily going to catch all cases. For instance, v=$(printf '%010d' 0) [[ $v == +($v) ]] will run (slowly) to successful completion without exceeding any stack limit. So the problem becomes finding the appropriate recursion limit. -- ``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/
Re: [PATCH] Fix foreground dead jobs in trap handlers reported like background ones in `jobs'
On 10/8/22 9:09 AM, Koichi Murase wrote: Thank you for your reply and sorry for the late reply. 2022年10月4日(火) 0:56 Chet Ramey : I expect the same behavior of `f1' and `f2' as far as there are no background jobs. Why? f2 calls `jobs', and so requests information in a particular format, which may or may not be the same format as the default (compact) format bash uses when it reports job status before printing a prompt. My point is *not* about the format of the output of `jobs', but whether `jobs' should print the entries of foreground dead jobs, to begin with. Yes. I believe that `jobs' should print the status of jobs that the shell would otherwise notify the user about. This includes foreground jobs that are killed by a signal other than SIGINT/SIGPIPE. -- ``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/
New instances of Bash should ignore and reset BASH_ARGV0
This doesn't look right to me: # export BASH_ARGV0=fdsafasfas # bash # echo "$BASH_ARGV0|$0" fdsafasfas|fdsafasfas # echo $BASH_VERSION 5.2.0(1)-release -- konsolebox
