memleak in execute_function?

Hey all, I suspect there is a memleak in bash. I use the bash 4.4.23 (fedora Linux) with ASAN. Then I run some testcases and find a memleak. I think we need to free this "gs" in execute_cmd.c *gs* = sh_getopt_save_istate (); if (subshe

syntax errors produced by interaction between process substitution and a SIGCHLD trap

Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: darwin17.7.0 Compiler: clang Compilation CFLAGS: -g -O2 -Wno-parentheses -Wno-format-security uname output: Darwin 6841b968 18.6.0 Darwin Kernel Version 18.6.0: Thu Apr 25 23:16:27 PDT 2019; root:xnu-4903.261.4~

Re: Optimize bash string handling?

On 7/26/19 5:55 AM, Alkis Georgopoulos wrote: > While handling some big strings, I noticed that bash is a lot slower > than other shells like dash, posh and busybox ash. > I came up with the following little benchmark and results. > While the specific benchmark isn't important, maybe some developer

Re: memleak in execute_function?

On 7/31/19 11:26 AM, fireshen wrote: > Hey all, > > I suspect there is a memleak in bash. > > I use the bash 4.4.23 (fedora Linux) with ASAN. Then I run some testcases > and find a memleak. It's not a memory leak. It's a false positive from asan or valgrind. The `gs' object is freed by maybe_r

Re: memleak in execute_function?

Yeah, I agree with your opinion, in the branch "if (subshell == 0) ", we have the function "maybe_restore_getopt_state" to free gs; however, in the branch "else", it seems like forget to free "gs", or we don't have to free it？ -- Sent from: http://gnu-bash.2382.n7.nabble.com/

Re: memleak in execute_function?

On 7/31/19 8:57 PM, fireshen wrote: > Yeah, I agree with your opinion, in the branch "if (subshell == 0) ", we have > the function "maybe_restore_getopt_state" to free gs; however, in the branch > "else", it seems like forget to free "gs", or we don't have to free it？ We don't have to free it. If