search

byteduck / duckOS

An x86 monolithic kernel and operating system written in modern C++. Comes with in-house graphical applications and command line utilities, plus ports of existing software. And yes, it runs DOOM!
GNU General Public License v3.0
618 stars 25 forks source link

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

Closed pawlos closed 1 year ago

pawlos commented 1 year ago

Information

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

Logs

N/A

Screenshot

N/A

Environment

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 commented 1 year ago

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 commented 1 year ago

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

byteduck commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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