Re: write() not retried after EINTR in printf and echo
On 12/18/18 8:06 PM, Bize Ma wrote: > In here: > https://lists.gnu.org/archive/html/bug-bash/2018-01/msg00032.html > > > You promised: > > The > next version of bash will install its SIGWINCH handler with SA_RESTART. > > > > Yet: > Still a bug in bash version 5 And yet, when you look at the source, the signal handlers are installed with SA_RESTART. For example, /* Let's see if we can keep SIGWINCH from interrupting interruptible system calls, like open(2)/read(2)/write(2) */ #if defined (SIGWINCH) if (sig == SIGWINCH) act.sa_flags |= SA_RESTART; /* XXX */ #endif in sig.c:set_signal_handler() and # if defined (SIGWINCH) act.sa_flags = (sig == SIGWINCH) ? SA_RESTART : 0; # else act.sa_flags = 0; # endif /* SIGWINCH */ in lib/readline/signals.c:rl_set_sighandler(). -- ``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/
memory leak in bash only during boot up in Bash-3.2.48
create a shell script from below given code. name it testing.sh.
#!/bin/bash
logger "Started testing"
while(true); do
while (true); do ls > /dev/null ; done
done
Steps.
# chmod 755 /root/testing.sh
modify any /etc/init.d/"service" file add "/root/testing.sh" inside the
start case.
"service" is any service file starting during start up.
Make sure above service is started during the startup.
Example :
Add testing to audit init script
start(){
echo -n "Starting testing.sh"
/root/testing.sh &
After boot up
root@localhost:/root> ps fax | grep testing
751 ? S 0:11 /bin/bash /root/testing.sh
9684 ttyS0 S+ 0:00 \_ grep testing
root@localhost:/root> cat /proc/751/smaps | grep -A10 heap
01419000-016ad000 rw-p 00:00 0 [heap]
Size: 2640 kB
Rss: 2536 kB
Pss: 2536 kB
Shared_Clean: 0 kB
Shared_Dirty: 0 kB
Private_Clean: 0 kB
Private_Dirty: 2536 kB
Referenced: 2536 kB
Swap: 0 kB
KernelPageSize: 4 kB
root@localhost:/root> cat /proc/751/smaps | grep -A10 heap
01419000-016ce000 rw-p 00:00 0 [heap]
Size: 2772 kB
Rss: 2740 kB
Pss: 2734 kB
Shared_Clean: 0 kB
Shared_Dirty: 12 kB
Private_Clean: 0 kB
Private_Dirty: 2728 kB
Referenced: 2740 kB
Swap: 0 kB
KernelPageSize: 4 kB
But when we are testing the same on Bash-4.4.0, its not consuming the memory
and steady as well, below are the logs
root@localhost:/root> ps fax | grep testing
964 ?S 0:02 /bin/bash /root/testing.sh
11484 pts/0S+ 0:00 \_ grep testing
root@localhost:/root> cat /proc/964/smaps | grep -A10 heap
00b1b000-00b32000 rw-p 00:00 0
[heap]
Size: 92 kB
Rss: 88 kB
Pss: 88 kB
Shared_Clean: 0 kB
Shared_Dirty: 0 kB
Private_Clean: 0 kB
Private_Dirty:88 kB
Referenced: 88 kB
Swap: 0 kB
KernelPageSize:4 kB
root@localhost:/root> cat /proc/964/smaps | grep -A10 heap
00b1b000-00b32000 rw-p 00:00 0
[heap]
Size: 92 kB
Rss: 88 kB
Pss: 60 kB
Shared_Clean: 0 kB
Shared_Dirty: 56 kB
Private_Clean: 0 kB
Private_Dirty:32 kB
Referenced: 88 kB
Swap: 0 kB
--
Sent from: http://gnu-bash.2382.n7.nabble.com/
Memory continusely increase
Hi all, I did a test about run a bash scriplt never quit,but met a memory usage issue that cause used memory continuous increase. This issue was present in bash-3.2.x, bash-4.0.x, bash-4.1.x, bash-4.2.x, bash-4.3.x. However, This issue was disappeared in bash-4.4.0, I can't trace which patch fixed the issue or which new feature was introduced in bash-4.4.0. Here is bash script: -- #!/bin/bash logger "Started testing" while(true);do while (true); do ls > /dev/null done done --- root@localhost:/root> cat /proc/767/smaps |grep -A10 heap 01ba5000-01be8000 rw-p 00:00 0 [heap] Size:268 kB Rss: 152 kB Pss: 152 kB Shared_Clean: 0 kB Shared_Dirty: 0 kB Private_Clean: 0 kB Private_Dirty: 152 kB Referenced: 152 kB Swap: 0 kB KernelPageSize:4 kB -- root@localhost:/root> cat /proc/767/smaps |grep -A10 heap 00d4c000-00e55000 rw-p 00:00 0 [heap] Size: 1060 kB Rss:1048 kB Pss:1048 kB Shared_Clean: 0 kB Shared_Dirty: 0 kB Private_Clean: 0 kB Private_Dirty: 1048 kB Referenced: 1048 kB Swap: 0 kB KernelPageSize:4 kB -- Could someone help to tell me which part of changes in bash-4.4.0, that would be give me a direction backport code changes from bash-4.4 to bash-3.2.x and bash-4.3.x. Thanks, Chen. -- Sent from: http://gnu-bash.2382.n7.nabble.com/
Memory continuesly increase
Hi all,I did a test about run a bash scriplt never quit,but met a memory usage issue that cause used memory continuous increase.This issue was present in bash-3.2.x, bash-4.0.x, bash-4.1.x, bash-4.2.x, bash-4.3.x. However, This issue was disappeared in bash-4.4.0, I can't trace which patch fixed the issue or which new feature was introduced in bash-4.4.0.Here is bash script:--#!/bin/bashlogger "Started testing"while(true);do while (true); dols > /dev/null donedone---root@localhost:/root> cat /proc/767/smaps |grep -A10 heap01ba5000-01be8000 rw-p 00:00 0 [heap]Size:268 kBRss: 152 kBPss: 152 kBShared_Clean: 0 kBShared_Dirty: 0 kBPrivate_Clean: 0 kBPrivate_Dirty: 152 kBReferenced: 152 kBSwap: 0 kBKernelPageSize:4 kB--root@localhost:/root> cat /proc/767/smaps |grep -A10 heap00d4c000-00e55000 rw-p 00:00 0 [heap]Size: 1060 kBRss:1048 kBPss: 1048 kBShared_Clean: 0 kBShared_Dirty: 0 kBPrivate_Clean: 0 kBPrivate_Dirty: 1048 kBReferenced: 1048 kBSwap: 0 kBKernelPageSize:4 kB--Could someone help to tell me which part of changes in bash-4.4.0, that would be give me a direction backport code changes from bash-4.4 to bash-3.2.x and bash-4.3.x.Thanks,Chen. -- Sent from: http://gnu-bash.2382.n7.nabble.com/
Re: Memory continusely increase
+ Adding Abhishek
Hi Chen and Abhishek, it seems you might work on the same team since
you sent the exact same bug report:
- http://lists.gnu.org/archive/html/bug-bash/2018-12/msg00059.html
- http://lists.gnu.org/archive/html/bug-bash/2018-12/msg00058.html
- http://lists.gnu.org/archive/html/bug-bash/2018-12/msg00057.html
On Wed, Dec 19, 2018 at 6:45 AM jake wrote:
>
> Hi all,
>
> I did a test about run a bash scriplt never quit,but met a memory usage
> issue that cause used memory continuous increase.
> This issue was present in bash-3.2.x, bash-4.0.x, bash-4.1.x, bash-4.2.x,
> bash-4.3.x. However, This issue was disappeared in bash-4.4.0, I can't trace
> which patch fixed the issue or which new feature was introduced in
> bash-4.4.0.
These versions (3.2, 4.0, 4.1, 4.2 and 4.3) are fairly old. Any
particular reason you're not upgrading to 4.4 instead?
> Could someone help to tell me which part of changes in bash-4.4.0, that
> would be give me a direction backport code changes from bash-4.4 to
> bash-3.2.x and bash-4.3.x.
(...)
> while(true);do
> while (true); do
>ls > /dev/null
> done
> done
My guess is that it's a memory leak in subshell creation. You don't
need that subshell by the way, the following should work just fine:
while :; do
...
done
The parenthesis are not only not needed, but they add overhead because
a new subshell is created every time.
Anyways, looking at the changelog for 4.4, it looks like it's going to
be time consuming to find / backport this, since there are many memory
leaks that were fixed:
$ grep -i leak ./CHANGES-4.4
c. Fixed several memory leaks.
a. Fixed a memory leak when processing ${!var[@]}.
i. Fixed a memory leak in the code that removes duplicate history entries.
b. Fixed a memory leak in programmable completion.
i. Fixed a memory leak when processing declare commands that perform compound
s. Fixed a memory leak that occurred when interrupting brace expansions
dd. Fixed a memory leak when creating local array variables and assigning to
p. Fixed a potential file descriptor leak when dup2() fails while performing a
i. Some memory leaks caused by signals interrupting filename completion have
I'll try to go through some of these changes later today to see if
anything evident comes up. I still recommend just upgrading to 4.4 if
you can though. Running outdated versions is never fun.
Re: Bash build issues in `devel' branch due to -Werror compiler flag
On Mon, Dec 17, 2018 at 6:31 AM Chet Ramey wrote: (...) > Good. This is the kind of feedback I want from enabling this option during > the pre-release period. Thanks for taking the time. Thank you! Bash `devel' builds fine for me now.
Re: write() not retried after EINTR in printf and echo
Chet Ramey () wrote:
> And yet, when you look at the source, the signal handlers are installed
> with SA_RESTART. For example,
>
> # if defined (SIGWINCH)
> act.sa_flags = (sig == SIGWINCH) ? SA_RESTART : 0;
> # else
> act.sa_flags = 0;
> # endif /* SIGWINCH */
>
> in lib/readline/signals.c:rl_set_sighandler().
>
>
True for SIGWINCH, but "write error: Interrupted system call"
is still exposed to users (which it shouldn't) for other signals:
{ pid=$BASHPID; trap : USR1;
(sleep 1; kill -USR1 "$pid") &
printf %010d 1;
} | sleep 20
Error on arithmetic evaluation of `~0`.
This is the third time I am reporting this issue.
This fails:
var=(hello); echo "${var[~0]}"
syntax error: operand expected ...
While this works:
var=(hello); echo "${var[ ~0]}"
hello
It is also interesting that this fails:
var=hello; echo "${var[ ~0]}"
bash: var: bad array subscript
Isn't `var[0]` valid and equivalent to `var` ?
This was "supposed" to be resolved in a dev version,
but is still present on bash 5.
Re: Memory continusely increase
Eduardo Bustamante 于2018年12月20日周四 上午1:58写道：
>
> + Adding Abhishek
> On Wed, Dec 19, 2018 at 6:45 AM jake wrote:
> >
> > Hi all,
> >
> > I did a test about run a bash scriplt never quit,but met a memory usage
> > issue that cause used memory continuous increase.
> > This issue was present in bash-3.2.x, bash-4.0.x, bash-4.1.x, bash-4.2.x,
> > bash-4.3.x. However, This issue was disappeared in bash-4.4.0, I can't trace
> > which patch fixed the issue or which new feature was introduced in
> > bash-4.4.0.
>
> These versions (3.2, 4.0, 4.1, 4.2 and 4.3) are fairly old. Any
> particular reason you're not upgrading to 4.4 instead?
It has deployed to our devices, so if direct upgrade to bash-4.4, we
need spend about
one year to verify it.
>
> > Could someone help to tell me which part of changes in bash-4.4.0, that
> > would be give me a direction backport code changes from bash-4.4 to
> > bash-3.2.x and bash-4.3.x.
>
> (...)
>
> > while(true);do
> > while (true); do
> >ls > /dev/null
> > done
> > done
>
> My guess is that it's a memory leak in subshell creation. You don't
> need that subshell by the way, the following should work just fine:
>
> while :; do
> ...
> done
>
> The parenthesis are not only not needed, but they add overhead because
> a new subshell is created every time.
This issue still present even remove the parenthesis.
As you said, the memory leak in subshell creation. The subshell create
in every loop and
that scirpt is infinite loop that would be cause create many Child
processes, maybe there
have some resource don't be release when the child process has exited.
below is the calling process：
execute_command_internal() (loop-start)
|
execute_in_subshell()
|
execute_command_internal()
|
execute_simple_command()
|
execute_command_internal()
|
execute_simple_command()
|_(loop-start)
__
> Anyways, looking at the changelog for 4.4, it looks like it's going to
> be time consuming to find / backport this, since there are many memory
> leaks that were fixed:
>
> $ grep -i leak ./CHANGES-4.4
> c. Fixed several memory leaks.
> a. Fixed a memory leak when processing ${!var[@]}.
> i. Fixed a memory leak in the code that removes duplicate history entries.
> b. Fixed a memory leak in programmable completion.
> i. Fixed a memory leak when processing declare commands that perform compound
> s. Fixed a memory leak that occurred when interrupting brace expansions
> dd. Fixed a memory leak when creating local array variables and assigning to
> p. Fixed a potential file descriptor leak when dup2() fails while performing
> a
> i. Some memory leaks caused by signals interrupting filename completion have
>
>
> I'll try to go through some of these changes later today to see if
> anything evident comes up. I still recommend just upgrading to 4.4 if
> you can though. Running outdated versions is never fun.
Thanks for your efforts:)
Thanks,
Chen.
Terminating background bash kills the parent?
Open a new terminal like xterm, change prompt to something like: PS1=' $SHLVL $ ' Start a couple of bash subshells: 1 $ bash 2 $ bash 3 $ echo $$ 9371 Suspend the last one: 3 $ suspend [1]+ Stopped bash 2 $ echo $$ 9313 2 $ Make the suspended shell continue: 2 $ kill -CONT 9371 The parent gets killed 1 $ echo $$ 9034 1 $ Take a look at: https://unix.stackexchange.com/questions/379507/weird-terminating-background-bash-kills-the-parent
