Re: Memory leaks in bash-4.4.0
On 1/29/17 6:48 PM, Bruce Dubbs wrote: > Bash Version: 4.4 > Patch Level: 0 > Release Status: release > > Description: > >When running regression tests on libinput, I get two different leaks > identified by valgrind. The files below are not a part of libinput but are > a part of bash. What is libinput? >==10733== 11 bytes in 1 blocks are definitely lost in loss record 81 of 290 >==10733==at 0x4C2AACD: malloc (vg_replace_malloc.c:299) >==10733==by 0x46F7BD: xmalloc (xmalloc.c:112) >==10733==by 0x469598: set_default_locale (locale.c:81) >==10733==by 0x419950: main (shell.c:411) >==10733== http://lists.gnu.org/archive/html/bug-bash/2015-07/msg00073.html >==10733== 17 bytes in 1 blocks are definitely lost in loss record 112 of > 290 >==10733==at 0x4C2AACD: malloc (vg_replace_malloc.c:299) >==10733==by 0x46F7BD: xmalloc (xmalloc.c:112) >==10733==by 0x4524EA: make_dev_fd_filename (subst.c:5692) >==10733==by 0x4524EA: process_substitute (subst.c:5751) >==10733==by 0x4524EA: expand_word_internal (subst.c:9172) >==10733==by 0x454E33: shell_expand_word_list (subst.c:10565) >==10733==by 0x454E33: expand_word_list_internal (subst.c:10688) >==10733==by 0x42F14E: execute_simple_command (execute_cmd.c:4153) >==10733==by 0x43134B: execute_command_internal (execute_cmd.c:802) >==10733==by 0x432BDD: execute_command (execute_cmd.c:405) >==10733==by 0x41BD51: reader_loop (eval.c:180) >==10733==by 0x41: main (shell.c:792) It would help if there were a short reproducer for this, so I can verify it. > I was not able to trace everything through, but xmalloc.c:112 does: > > temp = malloc (bytes); > > and as best I can tell, temp is never freed. xmalloc is a malloc wrapper, and `temp' is the return value from the function. 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/
$$'...' parsing bug?
This came up on comp.unix.shell: There appears to be a parsing problem in bash where the sequence $$'...' is treated as $'...', and $$"..." as $"...", when inside $(...). $ echo 'x\nx' x\nx $ echo $'x\nx' x x $ echo $$'x\nx' 86293x\nx $ echo $(echo $'x\nx') x x $ echo $(echo $$'x\nx') x x This is with bash 4.4.12... but a quick check shows the same behavior with 4.2.37. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: Memory leaks in bash-4.4.0
Chet Ramey wrote: On 1/29/17 6:48 PM, Bruce Dubbs wrote: Bash Version: 4.4 Patch Level: 0 Release Status: release Description: When running regression tests on libinput, I get two different leaks identified by valgrind. The files below are not a part of libinput but are a part of bash. What is libinput? https://www.freedesktop.org/software/libinput/ ==10733== 11 bytes in 1 blocks are definitely lost in loss record 81 of 290 ==10733==at 0x4C2AACD: malloc (vg_replace_malloc.c:299) ==10733==by 0x46F7BD: xmalloc (xmalloc.c:112) ==10733==by 0x469598: set_default_locale (locale.c:81) ==10733==by 0x419950: main (shell.c:411) ==10733== http://lists.gnu.org/archive/html/bug-bash/2015-07/msg00073.html ==10733== 17 bytes in 1 blocks are definitely lost in loss record 112 of 290 ==10733==at 0x4C2AACD: malloc (vg_replace_malloc.c:299) ==10733==by 0x46F7BD: xmalloc (xmalloc.c:112) ==10733==by 0x4524EA: make_dev_fd_filename (subst.c:5692) ==10733==by 0x4524EA: process_substitute (subst.c:5751) ==10733==by 0x4524EA: expand_word_internal (subst.c:9172) ==10733==by 0x454E33: shell_expand_word_list (subst.c:10565) ==10733==by 0x454E33: expand_word_list_internal (subst.c:10688) ==10733==by 0x42F14E: execute_simple_command (execute_cmd.c:4153) ==10733==by 0x43134B: execute_command_internal (execute_cmd.c:802) ==10733==by 0x432BDD: execute_command (execute_cmd.c:405) ==10733==by 0x41BD51: reader_loop (eval.c:180) ==10733==by 0x41: main (shell.c:792) It would help if there were a short reproducer for this, so I can verify it. I'll see what I can do. I was not able to trace everything through, but xmalloc.c:112 does: temp = malloc (bytes); and as best I can tell, temp is never freed. xmalloc is a malloc wrapper, and `temp' is the return value from the function. Yes, I know. The issue is that the caller, in this case set_default_locale or possibly main, never runs free on the allocated space. I tried to trace it in set_default_locale but there are a lot of paths and I didn't follow it all. I'll look some more and get back to you. -- Bruce
Re: Memory leaks in bash-4.4.0
On 1/30/17 2:34 PM, Bruce Dubbs wrote: >> xmalloc is a malloc wrapper, and `temp' is the return value from the >> function. > > Yes, I know. The issue is that the caller, in this case set_default_locale > or possibly main, never runs free on the allocated space. I tried to trace > it in set_default_locale but there are a lot of paths and I didn't follow > it all. I'll look some more and get back to you. Look at the link I included in my first reply; it explains the set_default_locale/setlocale issue. 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/
Re: $$'...' parsing bug?
On 1/30/17 10:31 AM, Christian Weisgerber wrote: > This came up on comp.unix.shell: > There appears to be a parsing problem in bash where the sequence > $$'...' is treated as $'...', and $$"..." as $"...", when inside > $(...). Yes, this is a problem. Thanks for the report. I've attached a one-line patch that fixes it. 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/ *** ../bash-4.4-patched/parse.y 2016-09-11 11:31:46.0 -0400 --- parse.y 2017-01-30 13:53:42.0 -0500 *** *** 4191,4195 FREE (nestret); } ! if MBTEST(ch == '$') tflags |= LEX_WASDOL; else --- 4213,4217 FREE (nestret); } ! if MBTEST(ch == '$' && (tflags & LEX_WASDOL) == 0) tflags |= LEX_WASDOL; else
history vs. poweroff
Man page says: When a shell with history enabled exits... and The shell exits by default upon receipt of a SIGHUP... However on slower systems, at the end of the day when the user issues the poweroff(8) command, all this might not complete, resulting in the entire day's of history getting thrown away. So perhaps on the man page add a word of caution. I even had to write a batch(1) script to stop (killall -1) my shells, then X-Windows, then finally poweroff. (a simple nohup script wasn't enough.) (But doing export PROMPT_COMMAND='history -a' is overkill).
