Strange problem with scheduler task switching

[YDeeps1]

I have managed to put together a task scheduler which allows you to schedule tasks (processes for now) which will jump to that process code (all code is linked with the OS, no ring 3 yet) and save all registers upon a timer interrupt and run the scheduler code. The thing works well, however I am having problems trying to get the stack to work. At first I tried simply simply allocating around 2KB with my simple heap allocator and then upon the process being scheduled, move the top of the stack into the esp and jump to the process and once the process yields control through a timer, moves the dedicated kernel stack pointer back into esp and run some quick C++ code to figure out which process to jump to next (and yes, the code does release the stack frame, not like that matters though since the kernel esp would go back to the original each time). My problem is that after around 2 seconds, undefined behaviour happens (sometimes I get a general protection fault, sometimes nothing happens and sometimes the struct containing process data gets corrupted and filled with random data) which leads me to believe there is some strange overwriting and code execution going on.

I'm looking for advice on the best way (or if I'm doing something wrong) for implementing a process stack and hopefully fixing this issue because after many nights I ran out of ideas. If you need anymore information feel free to ask (I do not just want to throw code at people).

Thank you!

[pvc]

2 KiB is a very little storage for a stack, unless you're running very restricted test code or targeting some kind of small, embedded system. Too little IMO. It would be very easy to overflow it with any bigger object or recursive algorithm.

[YDeeps1]

2 KiB is a very little storage for a stack, unless you're running very restricted test code or targeting some kind of small, embedded system. Too little IMO. It would be very easy to overflow it with any bigger object or recursive algorithm.

You might be right, but the problem occurs when the stack isn't even used by the program! I wrote a simple assembly function to just infinitely loop and all hell breaks loose after around 200 ticks from the PIT.

[deadmutex]

Are you in 64-bit mode? If so, then keep in mind that the stack is aligned to a 16-byte boundary before SS:RSP is pushed upon an interrupt.

[Octocontrabass]

moves the dedicated kernel stack pointer back into esp

Hold on a minute. In the "one kernel stack per thread" design, there is no dedicated kernel stack. Interrupts and system calls are handled on the current task's ring 0 stack, and switching to a different task is switching to a different ring 0 stack. When you eventually get code running in ring 3, how many ring 0 stacks do you plan to have?

(I do not just want to throw code at people)

Got a link to your code?

[YDeeps1]

Are you in 64-bit mode? If so, then keep in mind that the stack is aligned to a 16-byte boundary before SS:RSP is pushed upon an interrupt.

I'm in 32 bit mode.

[deadmutex]

2 KiB is a very little storage for a stack, unless you're running very restricted test code or targeting some kind of small, embedded system. Too little IMO. It would be very easy to overflow it with any bigger object or recursive algorithm.

You might be right, but the problem occurs when the stack isn't even used by the program! I wrote a simple assembly function to just infinitely loop and all hell breaks loose after around 200 ticks from the PIT.

In 32-bit mode, the processor still pushes at least 12 bytes to the stack upon an interrupt (it may push up to 24 bytes upon an exception.) Are you using 'iret' when your timer handler finishes?

[YDeeps1]

2 KiB is a very little storage for a stack, unless you're running very restricted test code or targeting some kind of small, embedded system. Too little IMO. It would be very easy to overflow it with any bigger object or recursive algorithm.

You might be right, but the problem occurs when the stack isn't even used by the program! I wrote a simple assembly function to just infinitely loop and all hell breaks loose after around 200 ticks from the PIT.

In 32-bit mode, the processor still pushes at least 12 bytes to the stack upon an interrupt (it may push up to 24 bytes upon an exception.) Are you using 'iret' when your timer handler finishes?

Yes! In fact I overwrite the return address and instead add the address for the main scheduler function, just so I don't have to do the far jumps myself.

[YDeeps1]

I'm doing a little debugging of my own right now to figure out different issues which likely link to this issue.

[YDeeps1]

Yeah I managed to fix it myself. I would explain how I got to the solution but I went through so many steps I can't remember
All I can say is the moral of the story is to not stay focused on one specific issue and explore to see if something else is causing that issue.