Why does MSVC generate SS traps itself?

[Ycep]

Hey, I was wondering why do VS 2012 generates SST on this occasion:

I was troubling with my multitasking scheduler (which changes PIT IRQ) which, after its initialization sleep() generates SS traps, randomly(every second or third boot ends up into SST).
Through, code snippets with same code as sleep() function work fluently (NOT inline).
If it could help in any reason:

Code: Select all

void sleep(int16 ms)
{
	uint need=ms+ticks;
	while(need>ticks)
	{
		//nextTask(), or whatever it needs to be in future
	}
}

I have runned BochsDbg and it shows on 23 bytes after sleep(), which somewhere around "while(need>ticks)". I'm really confused right now...

[MollenOS]

Your problem has to lie somewhere else, maybe in your task switching code instead, because the code itself would never cause any problems (except you should make ticks volatile, otherwise MSVC will optimize the loop to infinite loop instead)

[iansjack]

Debugging, and the Bochs log, should show you exactly where the code is faulting.

[Ycep]

Debugging, and the Bochs log, should show you exactly where the code is faulting.

Are you kidding me? Why didn't you readed my post?

Your problem has to lie somewhere else, maybe in your task switching code instead, because the code itself would never cause any problems (except you should make ticks volatile, otherwise MSVC will optimize the loop to infinite loop instead)

It is already volatile, but it happened inside sleep(), not in interrupt.

I ask again, why would MSVC compiler put SST flags?

[Octocontrabass]

I have runned BochsDbg and it shows on 23 bytes after sleep(), which somewhere around "while(need>ticks)". I'm really confused right now...

What is the instruction? What are the contents of the segment descriptor caches when the fault occurs?

[MollenOS]

Debugging, and the Bochs log, should show you exactly where the code is faulting.

Are you kidding me? Why didn't you readed my post?

Your problem has to lie somewhere else, maybe in your task switching code instead, because the code itself would never cause any problems (except you should make ticks volatile, otherwise MSVC will optimize the loop to infinite loop instead)

It is already volatile, but it happened inside sleep(), not in interrupt.

I ask again, why would MSVC compiler put SST flags?

But you see, no matter where it happens it might still be because of interrupts. If your task is returning from the scheduler (by switch_task or w/e you call it), and the data is incorrect, segments are incorrect or a stack is overwritten with invalid data (which in turn may cause the registers/segments you restore to be invalid), then it will fail at a seemingly innocent instruction, because that is the next instruction to be executed.

It's almost always because of your scheduler, interrupt or switch task code if your code fails randomly (or at innocent instructions). The fault does not lie with the sleep code. There is nothing in your sleep code that would cause an exception, and MSVC does not insert calls to exceptions randomly.

[iansjack]

Are you kidding me?

No.

You don't tell us what instruction caused the fault. What the contents of the registers are. What the contents of the stack are. You don't even bother to show us the relevant parts of the Bochs log. But you ask us to guess what you have done wrong.

I'm not kidding you, but I do seem to be overestimating your debugging ability.

[Ycep]

Let us see... What the heck is problem there.

Code: Select all

_declspec(naked) void NewPitIrq()
{
	_asm
	{
		inc [ticks]
	}
	if(ticks==ExecTime)
	{
		Thread thr=queue[Qbottom++];
		if(thr.type==0)
		{
			thr.type=EXECUTING_THREAD;
			if(ThreadAmount<17)ExecTime=ticks+Optimizer[ThreadAmount];
			//TODO ThreadAmount>250
			else ExecTime=ticks+1000/ThreadAmount;
			curThread=thr;
		}
	}
	_asm
	{
		mov dx, 0x20
		mov al, 0x20
		out dx, al
	}
	_asm
	{
		iretd
	}
}

Oh mein Gott... I did not initialized Qbottom and Qtop.
Now it generates "Invalid opcode".

[MollenOS]

I would not use inline assembly for IRQ handlers, it's prone to disasters. Code your IRQ handlers in pure assembly, and instead make calls to extern C functions. But that is only the start of your problems..

You do not save the current context before doing anything and you don't restore. This means that your IRQ handler modifies almost all registers, destroying the state before the IRQ happens, and thus results in unexpected behavior when the Irq returns. The stack is ruined too because you never take into account that the Irq pushes variables onto the stack.

[Ycep]

I would not use inline assembly for IRQ handlers, it's prone to disasters. Code your IRQ handlers in pure assembly, and instead make calls to extern C functions. But that is only the start of your problems..

You do not save the current context before doing anything and you don't restore. This means that your IRQ handler modifies almost all registers, destroying the state before the IRQ happens, and thus results in unexpected behavior when the Irq returns. The stack is ruined too because you never take into account that the Irq pushes variables onto the stack.

Thanks. I will stop a little bit with multithreading and go up to filesystems before I continue to mess around with it.