memleak in execute_function?

2019-07-31 Thread fireshen
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 (subshell == 0)
{
  begin_unwind_frame ("function_calling");
  push_context (var->name, subshell, temporary_env);
  /* This has to be before the pop_context(), because the unwinding of
 local variables may cause the restore of a local declaration of
 OPTIND to force a getopts state reset. */
  add_unwind_protect (maybe_restore_getopt_state, *gs*);
  add_unwind_protect (pop_context, (char *)NULL);
  unwind_protect_int (line_number);
  unwind_protect_int (line_number_for_err_trap);
  unwind_protect_int (function_line_number);
  unwind_protect_int (return_catch_flag);
  unwind_protect_jmp_buf (return_catch);
  add_unwind_protect (dispose_command, (char *)tc);
  unwind_protect_pointer (this_shell_function);
  unwind_protect_int (funcnest);
  unwind_protect_int (loop_level);
}
  else
push_context (var->name, subshell, temporary_env);  /* don't
unwind-protect for subshells */

Is this a bug? Just analyze the code.





--
Sent from: http://gnu-bash.2382.n7.nabble.com/



Re: memleak in execute_function?

2019-07-31 Thread fireshen
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/