Bug#911264: posh-0.13.1 'unset -f' broken

[or...@fredslev.dk]

Thank you for the quick fix, this seems to resolve the immediate
blocking issue. However it seems 'unset -f' still has problems.

I updated my example case slightly and found while 'unset -f' won't
block later commands if the function is not set, it will still do so
when the function is previously set.

I have attached the updated example which will fail with.

  9: echo: can't find function definition file

Note that there is also a nasty memory link if the function name
references the command inside the function.

  echo () echo foo; }

  echo

The attached example uses 'printf' instead to avoid this.


posh_unset2.sh
Description: application/shellscript

Bug#911395: posh-0.13.1 'unset -f' still broken

[or...@fredslev.dk]

Package: posh
Version: 0.13.2

Please see the previous issue for more discussion.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911264

I am opening a new issue because of the new release where issues still
persist.

The problem is that when using 'unset -f' to unset a function that has
been set it will make any commands that share the function's name
inaccessible instead.

The earlier fix works only if the function has not been set.

https://salsa.debian.org/clint/posh/commit/352c0b90a33ff6e398eb843e45665d37c36e18d1

I have attached a small test case to this e-mail which demonstrates the
issue where after 'unset -f echo' it will fail with:

  9: echo: can't find function definition file

The example works correctly with any other compatible shell.


posh_unset2.sh
Description: application/shellscript

Bug#911432: posh-0.13.2 massive memory leak / segfault

[or...@fredslev.dk]

Package: posh
Version: 0.13.2

I have found that when trying to use a function called 'echo' which
also calls the 'echo' builtin posh will hang while leaking several GBs
of memory and then segfaulting.

  echo () { echo foo; } ; echo

When I rebuilt posh with '-O0 -g' the amount of memory its leaks is
much greater and it seems like I will run out of swap before it
segfaults, maybe this is an infinite loop?

When running posh in gdb and getting a backtrace while posh is leaking
memory by pressing ctrl+c I find that gdb will also enter an infinite
loop...

I have attached a very large backtrace compressed with xz and a short
example script that will demonstrate the problem. Please take care when
testing it.


posh.log.xz
Description: application/xz


posh_leak.sh
Description: application/shellscript