Use of >/dev/null 2>&1 in called function causes "Abort(coredump)"

[xmnboy]

Description of problem:
Use of >/dev/null 2>&1 within a called function causes function to terminate with an Abort(coredump) message.

ksh version:
Version A 2020.0.0

# ksh --version
  version         sh (AT&T Research) 2020.0.0

Linux distribution:

# cat /etc/os-release
NAME="Ubuntu"
VERSION="20.04 LTS (Focal Fossa)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 20.04 LTS"
VERSION_ID="20.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=focal
UBUNTU_CODENAME=focal

How reproducible:
Discovered in a sourced script, but also reproducible within an executed script. No such problem with ksh93 version of ksh or with [lm]ksh fork. Not sure about earlier versions of ksh2020.

Steps to reproduce:
Source or execute this script from a ksh2020 prompt (testing was done as root user on an Ubuntu 20.04 system):

#!/bin/ksh
# generate coredump with ksh2020
# failure appears to be associated with '>/dev/null 2>&1' when inside a function
# set -x 
# path/to/this/script.sh

redirection() (
  { \unalias command; \unset -f command; } >/dev/null 2>&1 || :
  echo $1
)

echo ${.sh.version}
echo ${.sh.file}
echo ${.sh.file} >/dev/null
echo ${.sh.file} 2>&1
echo ${.sh.file} >/dev/null 2>&1

test=$(basename -- "$(redirection "${.sh.file}")")
echo "\$test =" $test

Actual results:

# ./test.sh
Version A 2020.0.0
/root/test.sh
/root/test.sh
./test.sh: line 18: 32761: Abort(coredump)
$test =

Expected results:

# ./test.sh
Version A 2020.0.0
/root/test.sh
/root/test.sh
$test = /root/test.sh

Additional info:
While initially debugging this issue I managed to also generate a free(): invalid pointer message along with the Abort(coredump) message. But I am not able to recall precisely what I did that resulted in that additional error message. Including it here because it may be of value regarding resolution of this problem.

[DavidMorano]

Hi @xmnboy

Use of >/dev/null 2>&1 within a called function ...

Thanks very much. I will take a look at this.
I think that I may be the only active developer on KSH2020 right now and it might take me some time to get to this.
But thanks anyway. And thanks for your testing of KSH2020 at all. There are other branches of KSH that are also being (somewhat) bug fixed currently. A search of the web (or GitHub) should find these. Some are more active than others. But most of these others are on the older "ksh93u+" branch, while KSH2020 was started from the newer (later) "ksh93v-" branch. Thanks again.

[DavidMorano]

Hi @xmnboy (Paul),

Use of >/dev/null 2>&1 within a called function causes function to terminate with an Abort(coredump) message.

Just to let you know, I have reproduced your bug exactly in my own development environment, including that "invalid pointer" message. I think that I fixed a bug in the "redirection" code already, but this new bug could be anywhere. I have not done a deep dive into it yet. But due to my schedule, it may be quite some time before I can get to this.
But thanks very much again for the report, and for your script that exactly reproduces the problem.

[DavidMorano]

Hi @xmnboy (Paul),

Please send me your email address (to 'morano@ieee.org') if you would like a work-around (and other information) for this bug.

[xmnboy]

Hi @DavidMorano,

No need for a workaround. I came up with an alternative approach to what I was trying to do that side-steps the bug. Thanks for taking the time to confirm that the bug is real. 😄 I don't recall precisely what I did to side-step it (this has been a very busy few months), I'd have to go back and look at the script's git history; if you want the workaround, when I get some time, I can go back and figure out what I did to side-step it.

I'm only too aware of the large number of ksh variants floating around out there. The script(s) in which I discovered this bug are, unfortunately, sourced scripts and need to run on a large number of customer platforms; thus I have no control over the sourcing shell, other than it must be a POSIX compatible shell. I ran into ksh2020 on an Ubuntu 20.04 platform we were testing against. I've also been testing against ksh93+ and lksh/mksh (both variants seem to be pretty prevalent).

No rush to get a fix on my account. Good luck with your ksh2020 project and thanks again for validating the bug.

--Paul