0

I have a problem with manual context switching. I am implementing kernel with multi-threading in C with assembly code by manually saving stack segment and stack pointer and restoring them. Simple tasks work but trying to execute a function that is placed deeper in the code does not behave good. What happens is that the cursor in cmd.exe where the program is being ran starts jumping from upper left to bottom left corner and the code writes itself over.

Can you suggest anything that could do something like that? What makes cursor go all the way up?

Ross Ridge
  • 38,414
  • 7
  • 81
  • 112
tokyo
  • 328
  • 4
  • 12
  • pfff... im new here, i didn't know that "hi" is being removed automatically.. :/ – tokyo Aug 18 '16 at 14:39
  • Since you are new: [help] and [mcve]. Clarify your question please: what `cmd.exe` has to do with a custom kernel? – Margaret Bloom Aug 18 '16 at 14:45
  • im making a model of a kernel as a .exe program written in C language. So it opens in cmd.exe. What it does is starting, pausing and continuing functions like they are threads. – tokyo Aug 18 '16 at 15:08
  • 1
    Please, again make a [mcve] or at least get in our shoes. How can we reasonably answer your question without seeing a line of code and any useful information? How are you preempting these functions? What context do you save? How do you handle the stack? As standing this question is unanswerable. – Margaret Bloom Aug 18 '16 at 15:21
  • Sorry for the insufficient amount of details.. But my code is all in classes and it would be a real pain for you going trough it. My question is what could be causing cursor in cmd to jump from bottom to top so i can analyze my code and find where is the bug. Thanks for your time! – tokyo Aug 18 '16 at 15:36
  • Sorry, as Margret Bloom said, we can't possibly answer your question. Until you provide an MCVE you're on your on your own. – Ross Ridge Aug 18 '16 at 15:45

1 Answers1

0

Considering "cmd.exe", I assume you run your "kernel" as a user-mode program in Windows.

In that case, the suspect is the stack guard page. Windows doesn't allocate RAM for the full stack; at the end of the allocated RAM there's one page which triggers a page fault. Windows intercepts this page fault, grows the stack, and then continues as if the stack already had the memory allocated. This critically depends on you not growing the stack by more than a single page.

If you're manually messing with the stack, the guard page may become corrupted and strange things can happen. You just can't have two kernels (Windows and your own) manage the same stack.

MSalters
  • 173,980
  • 10
  • 155
  • 350