答复: memory leak in bash

[wuzongyong (A)]

Well, the recent version runs ok, I just wan't to find the commit solving this 
bug.

Thanks,
Zongyong Wu

-邮件原件-
发件人: Eduardo Bustamante [mailto:dual...@gmail.com] 
发送时间: 2017年5月11日 22:39
收件人: wuzongyong (A) 
抄送: bug-bash@gnu.org; Wanzongshun (Vincent) 
主题: Re: memory leak in bash

On Thu, May 11, 2017 at 3:47 AM, wuzongyong (A)  wrote:
[...]
> My bash version is  version 4.2.46(1)-release, valgrind version is  3.11.0 , 
> could someone help to tell me if it is a bug please? And I wanna to know the 
> deeply level reason.

Try with a more recent version. Version 4.2.46 is a few years old now.

dualbus@debian:~$ cat script
#! /bin/bash
rc_exit ()
{
exit 0
}
rc_exit

dualbus@debian:~$ valgrind bash ./script ==14004== Memcheck, a memory error 
detector ==14004== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et 
al.
==14004== Using Valgrind-3.12.0.SVN and LibVEX; rerun with -h for copyright 
info ==14004== Command: bash ./script ==14004== ==14004== ==14004== HEAP 
SUMMARY:
==14004== in use at exit: 0 bytes in 0 blocks
==14004==   total heap usage: 482 allocs, 482 frees, 31,142 bytes allocated
==14004==
==14004== All heap blocks were freed -- no leaks are possible ==14004== 
==14004== For counts of detected and suppressed errors, rerun with: -v 
==14004== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

dualbus@debian:~$ bash --version
GNU bash, version 4.4.11(1)-release (x86_64-pc-linux-gnu) Copyright (C) 2016 
Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Re: Compiling bash statically in 4.2/4.3/4.4 with GCC 6.1.0

[Chet Ramey]

On 5/11/17 10:56 AM, Steve Volumetric wrote:
> In addition to my previous email, I also tired older versions of bash,
> going back to 4.2
> 
> I get the exact same error with all of them with the only exception being
> that the error occurs on different lines, but it always boils down to this:
> 
> ./config.h:332:22: error: two or more data types in declaration specifiers
>  #define sig_atomic_t int

If you don't have the static C libraries installed -- and I don't know
whether they are an available package for your version of Linux -- no
configure test that requires compiling a program will succeed. It doesn't
matter, though, because even if you're able to construct a correct
config.h, the result won't link.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

Bash 4.4 on GCC 6.1.0 static build issue

[Steve Volumetric]

 Hello,

I get the configure script to accept --enable-static-link seemingly without
issue.
I'm using gcc 6.1.0 and when I do 'make' I get:


rm -f mksyntax
gcc  -DPROGRAM='"bash"' -DCONF_HOSTTYPE='"x86_64"'
-DCONF_OSTYPE='"linux-gnu"' -DCONF_MACHTYPE='"x86_64-unknown-linux-gnu"'
-DCONF_VENDOR='"unknown"' -DLOCALEDIR='"/p/home/adowns/bin/share/locale"'
-DPACKAGE='"bash"' -DSHELL -DHAVE_CONFIG_H   -I.  -I. -I./include -I./lib
-I./lib/intl -I/p/home/adowns/bash-4.4/lib/intl  -g -O2 -Wno-parentheses
-Wno-format-security  -static -L./lib/termcap -static -rdynamic  -g -O2
-Wno-parentheses -Wno-format-security -rdynamic -g -O2 -Wno-parentheses
-Wno-format-security  -o mksyntax ./mksyntax.c
In file included from ./mksyntax.c:23:0:
./config.h:356:22: error: two or more data types in declaration specifiers
 #define sig_atomic_t int

I did some googling to see what could be done, and the general consensus
seemed to be to add a semi-colon after 'int'.  So I opened up config.h,
made that adjustment and got the *exact* same error, just with a semi-colon
at the end.  I wanted to stop myself before I get involved with code
changes and see what the maintainers have to say.

Thank you for your time.

-vsteve

Compiling bash statically in 4.2/4.3/4.4 with GCC 6.1.0

[Steve Volumetric]

In addition to my previous email, I also tired older versions of bash,
going back to 4.2

I get the exact same error with all of them with the only exception being
that the error occurs on different lines, but it always boils down to this:

./config.h:332:22: error: two or more data types in declaration specifiers
 #define sig_atomic_t int

I'm starting to wonder if this is a matter of setting the C style right,
maybe it wants C89 or some other syntax?  I didn't see anything like that
specified as a requirement in either the readme, install, or faq...

Re: Infinite loop in rl_forward_word

[Chet Ramey]

On 5/11/17 10:42 AM, Eduardo Bustamante wrote:
> On Thu, May 11, 2017 at 9:31 AM, Chet Ramey  wrote:
> [...]
>> Yes, this is it. I fixed it yesterday.
> 
> Thanks. From the crashing inputs that I reported, is there any that is
> still unfixed that I can help with? When are you going to upload the
> next snapshot? (To see if I can resume fuzzing next weekend).

In practice, I get the majority of my work done on the weekends, so I
generally try to upload on Monday. I can snapshot something today; it's
an automated process.


-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

Re: memory leak in bash

[Eduardo Bustamante]

On Thu, May 11, 2017 at 3:47 AM, wuzongyong (A)  wrote:
[...]
> My bash version is  version 4.2.46(1)-release, valgrind version is  3.11.0 , 
> could someone help to tell me if it is a bug please? And I wanna to know the 
> deeply level reason.

Try with a more recent version. Version 4.2.46 is a few years old now.

dualbus@debian:~$ cat script
#! /bin/bash
rc_exit ()
{
exit 0
}
rc_exit

dualbus@debian:~$ valgrind bash ./script
==14004== Memcheck, a memory error detector
==14004== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==14004== Using Valgrind-3.12.0.SVN and LibVEX; rerun with -h for copyright info
==14004== Command: bash ./script
==14004==
==14004==
==14004== HEAP SUMMARY:
==14004== in use at exit: 0 bytes in 0 blocks
==14004==   total heap usage: 482 allocs, 482 frees, 31,142 bytes allocated
==14004==
==14004== All heap blocks were freed -- no leaks are possible
==14004==
==14004== For counts of detected and suppressed errors, rerun with: -v
==14004== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

dualbus@debian:~$ bash --version
GNU bash, version 4.4.11(1)-release (x86_64-pc-linux-gnu)
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Re: Infinite loop in rl_forward_word

[Chet Ramey]

On 5/11/17 8:03 AM, Eduardo Bustamante wrote:
> On Tue, May 9, 2017 at 9:28 AM, Eduardo Bustamante  wrote:
> [...]
> 
> From what I can tell, it seems like the problem is that `set-mark'
> allows you to set a negative rl_mark, and then you can use
> `exchange-point-and-mark' to place that negative rl_mark into
> rl_point.

Yes, this is it. I fixed it yesterday.

Chet


-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

memory leak in bash

[wuzongyong (A)]

Hi,

I met a memory leak to use valgrind run shell code below:

#! /bin/bash
rc_exit ()
{
exit 0
}
rc_exit

And the valgrind log just like that:

HEAP SUMMARY:
==27459== in use at exit: 21,968 bytes in 464 blocks
==27459==   total heap usage: 568 allocs, 104 frees, 29,714 bytes allocated
==27459==
==27459== 72 (32 direct, 40 indirect) bytes in 1 blocks are definitely lost in 
loss record 267 of 288
==27459==at 0x4C29BE3: malloc (vg_replace_malloc.c:299)
==27459==by 0x46A1AA: xmalloc (in /usr/bin/bash)
==27459==by 0x42B44A: make_bare_simple_command (in /usr/bin/bash)
==27459==by 0x42B525: make_simple_command (in /usr/bin/bash)
==27459==by 0x42839D: yyparse (in /usr/bin/bash)
==27459==by 0x41DEF9: parse_command (in /usr/bin/bash)
==27459==by 0x41DFBB: read_command (in /usr/bin/bash)
==27459==by 0x41E1BB: reader_loop (in /usr/bin/bash)
==27459==by 0x41C8BD: main (in /usr/bin/bash)
==27459==
==27459== LEAK SUMMARY:
==27459==definitely lost: 32 bytes in 1 blocks
==27459==indirectly lost: 40 bytes in 2 blocks
==27459==  possibly lost: 0 bytes in 0 blocks
==27459==still reachable: 21,896 bytes in 461 blocks
==27459== suppressed: 0 bytes in 0 blocks
==27459== Reachable blocks (those to which a pointer was found) are not shown.
==27459== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==27459==
==27459== For counts of detected and suppressed errors, rerun with: -v
==27459== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

My bash version is  version 4.2.46(1)-release, valgrind version is  3.11.0 , 
could someone help to tell me if it is a bug please? And I wanna to know the 
deeply level reason.


Thanks,
Zongyong Wu

Re: read -e allows execution of commands (edit-and-execute-command) as the shell's process user

[Eduardo Bustamante]

On Tue, May 9, 2017 at 3:28 PM, Chet Ramey  wrote:
[...]
> This would be a great project for someone who wanted to help.

Thanks. I'll familiarize myself with the tools and try to send a patch.

Bash doesn't handle C with acute accent properly during readline's rl_change_case

[Eduardo Bustamante]

The C with acute accent character: https://en.wikipedia.org/wiki/%C4%86

- Upper case
dualbus@debian:~$ printf '\U0106\n'
Ć

- Lower case
dualbus@debian:~$ printf '\U0107\n'
ć

Now, in bash, if you type in ć, then run readline `upcase-word' on it,
instead of ending up with the UTF-8 multibyte string for U+0106 (0xC4
0x86), you end up with 0x07 0x87.

The parameter expansion doesn't seem to have that problem so I think
it's a bug in readline:

dualbus@debian:~/src/gnu/bash$ a=ć; echo ${a^^}
Ć

dualbus@debian:~/src/gnu/bash$ locale
LANG=en_US.UTF-8
LANGUAGE=en_US:en
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=

(gdb) bt
#0  rl_change_case (count=1, op=1) at text.c:1339
#1  0x00525cad in rl_upcase_word (count=1, key=117) at text.c:1304
#2  0x004fe7a7 in _rl_dispatch_subseq (key=117, map=0x771d80
, got_subseq=0) at readline.c:851
#3  0x004fed6f in _rl_dispatch_subseq (key=27, map=0x772d90
, got_subseq=0) at readline.c:985
#4  0x004fe149 in _rl_dispatch (key=27, map=0x772d90
) at readline.c:797
#5  0x004fe0b9 in readline_internal_char () at readline.c:629
#6  0x004ff6a2 in readline_internal_charloop () at readline.c:656
#7  0x004fda12 in readline_internal () at readline.c:670
#8  0x004fd8d0 in readline (prompt=0x899ce8 "bash-4.4$ ") at
readline.c:374
#9  0x0042cae8 in yy_readline_get () at ./parse.y:1456
#10 0x00431a8b in yy_getc () at ./parse.y:1389
#11 0x00432328 in shell_getc (remove_quoted_newline=1) at ./parse.y:2289
#12 0x00430bb7 in read_token (command=0) at ./parse.y:3138
#13 0x0042c14e in yylex () at ./parse.y:2675
#14 0x00428abe in yyparse () at y.tab.c:1827
#15 0x004285ab in parse_command () at eval.c:294
#16 0x00428392 in read_command () at eval.c:338
#17 0x00428091 in reader_loop () at eval.c:140
#18 0x004253bb in main (argc=1, argv=0x7fffe498,
env=0x7fffe4a8) at shell.c:794

(gdb) p rl_line_buffer
$1 = 0x83a408 "ć"

(gdb) finish
Run till exit from #0  rl_change_case (count=1, op=1) at text.c:1339
0x00525cad in rl_upcase_word (count=1, key=117) at text.c:1304
1304  return (rl_change_case (count, UpCase));
Value returned is $2 = 0

(gdb) p rl_line_buffer
$3 = 0x83a408 "\a\207"

For some reason, rl_change_case thinks `c` is ASCII:

(gdb) call isascii((unsigned char)c)
$8 = 1

Re: Infinite loop in rl_forward_word

[Eduardo Bustamante]

On Tue, May 9, 2017 at 9:28 AM, Eduardo Bustamante  wrote:
[...]

>From what I can tell, it seems like the problem is that `set-mark'
allows you to set a negative rl_mark, and then you can use
`exchange-point-and-mark' to place that negative rl_mark into
rl_point.

A simple way of breaking this is by typing:
<-><5><\C-x><\C-x><-l> inside bash, and then
continue typing into readline. Or in other words, call set-mark with
-5, then type stuff, then call exchange-point-and-mark, then type more
stuff.

I think that the fix is:

dualbus@debian:~/src/gnu/bash$ git diff -- lib/readline/text.c
diff --git a/lib/readline/text.c b/lib/readline/text.c
index 095c0ef3..115de093 100644
--- a/lib/readline/text.c
+++ b/lib/readline/text.c
@@ -1699,7 +1699,7 @@ rl_backward_char_search (int count, int key)
 int
 _rl_set_mark_at_pos (int position)
 {
-  if (position > rl_end)
+  if (position > rl_end || position < 0)
 return 1;

   rl_mark = position;
@@ -1720,7 +1720,7 @@ rl_exchange_point_and_mark (int count, int key)
   if (rl_mark > rl_end)
 rl_mark = -1;

-  if (rl_mark == -1)
+  if (rl_mark < 0)
 {
   rl_ding ();
   return 1;

Re: {varname} redirection for a command or group leaves the file open

[Aldo Davide]

On Wed, May 10, 2017 at 8:52 PM, Pierre Gaston  wrote:

> See:
> https://lists.gnu.org/archive/html/bug-bash/2012-11/msg00040.html[https://lists.gnu.org/archive/html/bug-bash/2012-11/msg00040.html]
> Pierre
> PS: I'm with you ;)

Thanks for the link, I didn't find it in my earlier searches.

Well, that's disappointing. So there is no technical reason for this behavior 
other than copying the behavior of ksh. BTW zsh does the right thing and in the 
following scenario:

ls -lh /proc/self/fd {fd}>/dev/null

and it closes the file descriptor after the command has completed.