[BUG] Terminal does not accept input after CTRL-C

[pawlos]

Information

Terminal is not responding to keyboard input after sending CTRL-C the running program.

Logs

N/A

Screenshot

N/A

Environment

• WSL2
• QEMU 7.0.0

To Reproduce

1. Run the terminal
2. Execute cat (w/o any arguments)
3. Type some text + Enter -> text is displayed back
4. CTRL-C
5. Try typing another command on the terminal - no output visible

Additional context

I think the problem is that the terminal STDIN/OUT are not mapped back when the program is abruptly closed with CTRL-C. Tried to follow the code, but not been able to track the exact bug location.

[byteduck]

I've noticed this as well, and haven't gotten around to fixing it yet. I don't think it's a problem with the terminal (or probably even dsh) itself, but rather due to the waitpid syscall not unblocking the parent process properly after the child is interrupted.

That's just my theory though, I haven't dug into it too deeply yet. There are still quite a few bugs around blocking and waiting threads, and I've been meaning to refactor the way it works for a while.

[pawlos]

Thanks for the comment. I'll try to check the syscall lead.

[byteduck]

I did a little poking around this issue last night. Seems to be some weird issue with how the dead process is deleted after waitpid finishes. I'll whip out gdb and take a closer look in a bit.

[byteduck]

This is proving to be a really weird bug. I stepped through it with gdb, and it looks like at some point in destroying the process, the stack ends up mangled somehow. Upon returning from the kstd::Arc destructor for one of its VMRegions, it jumps to a weird, unrelated section of code. It's not even freeing the VMRegion in question, there's still at least one strong reference left. So it's not because we're unmapping that memory or something.

[byteduck]

I'm lumping this in with #48, since this is related to a lot of other problems with scheduling / blocking :)