Re: Question on $@ vs $@$@

[Robert Elz]

Date:Sun, 25 Aug 2024 04:08:58 +0200
From:Steffen Nurpmeso 
Message-ID:  <20240825020858.nrX4pFTm@steffen%sdaoden.eu>

  | (The only thinkable answer is that the step that my MUA does,
  | namely resolving $* as a single string first, does not happen,
  | right?

That's correct.   When (first) expanding $* the value of IFS
is irrelevant, except for expansions where field splitting won't
later be performed (ie: never would be performed, regardless of
the value of IFS) - eg: VAR=$* or more commonly "$*".

After the fields have been expanded, then the results of those
expansions are subject to field splitting, for which IFS is
relevant.

That is, given

set -- a b c

$* produces 3 fields, "a" "b" and "c" (not quoted of course)
which are then subject (individually) to field splitting.
If we had IFS=b then the middle field would turn into nothing,
leaving just "a" and "c".

  | I really have to carefully read the standard on Monday.)

For this see XCU 2.5.2, the descriptions of the expansions of
the special parameters, $@ and $* are the first two listed.
When unquoted, they're identical:

Expands to the positional parameters, starting from one, initially
producing one field for each positional parameter that is set. When
the expansion occurs in a context where field splitting will be
performed, any empty fields may be discarded and each of the non-empty
fields shall be further split as described in Section 2.6.5.

After that, when the expansion is in a context where field splitting
won't be performed, then $* and $@ are processed differently - with
$@ only being defined in a few cases in this circumstance.   2.6.5
says how IFS is used to (potentially) break those fields up info smaller
fields.

For $* in a non-field-splitting context, it goes on to say:

When the expansion occurs in a context where field splitting will
not be performed, the initial fields shall be joined to form a
single field with the value of each parameter separated by the first
character of the IFS variable if IFS contains at least one character,
or separated by a  if IFS is unset, or with no separation if
IFS is set to a null string.

If that happens, since we know we're in a context where field splitting
doesn't happen, we're done (just quote removal to follow - as not doing
field splitting usually also means not doing pathname expansion - though
some shells will do pathname expansion on the word after a redirect operator,
sometimes.)

kre

eval '<$(;)' causes Segmentation Fault

[youheng.lue]

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 
-ffat-lto-objects -fstack-protector-strong -Wformat -Werror=format-security 
-Wall

uname output: Linux sw-c-098 6.8.0-40-generic #40~22.04.3-Ubuntu SMP 
PREEMPT_DYNAMIC Tue Jul 30 17:30:19 UTC 2 x86_64 x86_64 x86_64 GNU/Linux

Machine Type: x86_64-pc-linux-gnu

 

Bash Version: 5.1

Patch Level: 16

Release Status: release

 

Description:

Certain strings when given to `eval` cause a Segmentation Fault in bash.

 

Repeat-By:

1. Create a script, i.e. `poc.sh` with the problematic string

2. Execute `bash poc.sh`

 

Example:

$ cat poc.sh

eval '<$(;)'

 

$ bash poc.sh

poc.sh: command substitution: line 2: syntax error near unexpected 
token `;'

poc.sh: command substitution: line 2: `;)'

poc.sh: line 1: 42674 Segmentation fault  (core dumped)

 

Related Issues:

All the following scripts can create a Segmentation Fault

eval '<$[;]'

eval '<$(;)'

eval '<${;}'

eval '<$[|]'

eval '<$(|)'

eval '<${|}'

 

GDB:

The Segmentation Fault appears in `parse_and_execute`.

At some point $rax gets corrupted and the program tries

to read from $rax=0x, which is an invalid address

 

$ gdb -nx bash

Reading symbols from bash...

(No debugging symbols found in bash)

(gdb) set follow-fork-mode child

(gdb) run poc.sh

Starting program: /usr/bin/bash poc.sh

[Thread debugging using libthread_db enabled]

Using host libthread_db library 
"/lib/x86_64-linux-gnu/libthread_db.so.1".

[Attaching after Thread 0x77f6f740 (LWP 46590) fork to child 
process 46593]

[New inferior 2 (process 46593)]

[Detaching after fork from parent process 46590]

[Inferior 1 (process 46590) detached]

[Thread debugging using libthread_db enabled]

Using host libthread_db library 
"/lib/x86_64-linux-gnu/libthread_db.so.1".

poc.sh: command substitution: line 3: syntax error near unexpected 
token `;'

poc.sh: command substitution: line 3: `;)'

 

Thread 2.1 "bash" received signal SIGSEGV, Segmentation fault.

[Switching to Thread 0x77f6f740 (LWP 46593)]

0x55601f27 in parse_and_execute ()

(gdb) x/i $rip

=> 0x55601f27 :  cmpb   $0x0,(%rax)

(gdb) x/gx $rax

0x: Cannot access memory at address 0x

(gdb) bt

#0  0x55601f27 in parse_and_execute ()

#1  0x556037a1 in evalstring ()

#2  0x555a798c in ?? ()

#3  0x555a06b4 in ?? ()

#4  0x555a1b5d in execute_command_internal ()

#5  0x555a41b8 in execute_command ()

#6  0x555953cb in reader_loop ()

#7  0x55586c46 in main ()

Re: eval '<$(;)' causes Segmentation Fault

[Lawrence Velázquez]

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 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 the scripts via stdin avoids the
segfault.

% cat /tmp/poc.bash
eval '<$[;]'
% ./bash /tmp/poc.bash
/tmp/poc.bash: line 1: ;: arithmetic syntax error: operand expected 
(error token is ";")
/tmp/poc.bash: line 1: 55480 Segmentation fault: 11
% ./bash  eval '<$(;)'
> eval '<$(|)'

Current devel doesn't segfault with these.  Maybe because of the
comsub parser rewrite?


> eval '<${|}'

Current devel doesn't segfault with this, either.


-- 
vq

[bug #66127] [Bash x86] Increased memory bandwidth due to background commands

[korantli]

URL:
  

 Summary: [Bash x86] Increased memory bandwidth due to
background commands
   Group: The GNU Bourne-Again SHell
   Submitter: korantli
   Submitted: Mon 26 Aug 2024 03:10:18 AM UTC
Category: None
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any


___

Follow-up Comments:


---
Date: Mon 26 Aug 2024 03:10:18 AM UTC By: korantli 
Hey guys，we found a strange issue about bash

In bash version: v4.2.46\v4.4.20\v5.2, we found following issue.

When we run the script blow：
#! /bin/bash
while :; do
echo "test" & 
  
# wait $!
sleep 1
done

We found that background commands cause memory bandwidth to increase with
runtime by intel's tool pcm-memory（https://github.com/intel/pcm）. 

When first start running the script, the bandwidth is about 50-100MB/s. But
after 3 days, it increases to 1000-1500MB/s.

Besides, we found the script's RSS(watched by pidstat) will continue to
increase.

We found when issue occurred, the script's
_int_free\_int_malloc\malloc_consolidate is first 3 top hot perf events
collected by "perf record -e mem-loads -e mem-stores -g -p  xxx -- sleep 10".

However when first start running script, they are not the hottest. 

We believe the these mem events is the key reason why memory bandwidth
increasing. However, we can't find out why bash do it.

Also, we found "(echo "test" &)" will fix this issue.

It will be so grateful if anyone could help~







___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/


signature.asc
Description: PGP signature