ksh: shell crashes when read times out
[ 6:38 PM][ttys001][~/test/bz573936]
[211] mbp13 $ type ksh
ksh is a tracked alias for /usr/local/bin/ksh
[ 6:38 PM][ttys001][~/test/bz573936]
[212] mbp13 $ ksh
[ 6:38 PM][ttys001][~/test/bz573936]
[213] mbp13 $ TMOUT=5
[ 6:38 PM][ttys001][~/test/bz573936]
[214] mbp13 $ read
[ 6:39 PM][ttys001][~/test/bz573936]
[215] mbp13 $
shell will timeout in 60 seconds due to inactivity
Memory fault
[ 6:39 PM][ttys001][~/test/bz573936]
[215] mbp13 $
I read https://bugzilla.redhat.com/show_bug.cgi?id=573936 and tested it, didn’t see the behavior the bug talked about, figured it must no longer be a problem.
Then the window I was running ksh in closed.
The read
timed out after 5 seconds, and the prompt came back. Then ksh popped the timeout message and the memory fault, and the shell crashed.
I can’t make it happen if I put it in a script and call the script, but it happens repeatably if I do it interactively. If I don’t set a timeout and just let the read
sit there, it doesn’t crash.
(macOS 10.15.6, Version AJM 93u+m 2020-07-29)
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Comments: 49
Commits related to this issue
- Remove obsolete and partial crash workaround (re: 61437b27, 51b2e360) The fix for #103 was incomplete and papered over the problem. The real fix for this bug was applied in 51b2e36 on 20th February 2... — committed to ksh93/ksh by McDutchie 2 years ago
- Remove obsolete and partial crash workaround (re: 61437b27, 51b2e360) The fix for #103 was incomplete and papered over the problem. The real fix for this bug was applied in 51b2e36 on 20th February 2... — committed to ksh93/ksh by McDutchie 2 years ago
I’m getting nowhere with trying to reproduce any variant of this crash, even when using your complete prompt setup. I just can’t get it to malfunction at all. There must still be something in your setup that we’re missing.However, based on your crash backtrace, I came up with something. The backtrace includes
comsubst()
andsh_subshell()
, indicating that the crash occurs while a command substitution is being executed. Job control is disabled in command substitutions, so it doesn’t seem to make sense to calljob_unpost()
(the function that crashed) while in a command substitution. It’s a bit of a shot in the dark, but I’m curious if the following patch makes any difference on your end…MOST interesting! If I reset PS1, I can’t make the segfault occur. See here, where first it occurs, then reset PS1, then it doesn’t occur. I have
set -b
for this test.My usual prompt is:
Which ends up being this after the discipline function gets through with it…
And here is prompt.ksh.
Results… it hasn’t crashed on 10.15.6, it hasn’t crashed on 10.14.6.
My self-imposed carelessness last night with copying around versions of the source tree did not lead to verifiable testing (hence the now-deleted report of a worse crash). That was entirely on me and I apologize for the noise.
I ran it all day on 10.15.6 and it didn’t crash, either line editing or trying to force the read timeout segfault.
Amusingly, I put it on 10.14.6 and the first thing I got was the background job hang. 😃. Nothing else to report so far.
set -o notify
is NOT broken with this one, as outlined by @JohnoKing in https://github.com/ksh93/ksh/commit/e805c7d9b15dab373d23749f6a2c777e8cd5126a#commitcomment-41290508.I have not been able to crash it with this patch. Has anyone else? This is like one of those things where you visit the doctor and say “it hurts when I do this…” and the only thing the doctor can say is “well, don’t do that?”
I can confirm that with this patch, I no longer get the crash with either my complex
PS1
or the minimum reproducer.