OSDev.org

I have been using Qemu to test my OS, and have found some issues with it.

Firstly, sometimes I will build my OS (using my automated script) and it'll be fine, and Qemu will start, but only the kernel will load, and then it reaches a certain point and it will freeze. There is nothing in the code to do that. But then I will close Qemu and make no changes to the code, rebuild and run Qemu again and it will work fine. Whats that about? It's annoying as hell.

Second, when I have my OS running, and I switch focus from Qemu back to Qemu, my kernel will randomly crash. But if I keep focus, there are no problems. How can I fix this?

_JL_

I sometimes make rebuild and run my code from the same code and get different results with bochs to....
Jules

RACE CONDITIONS!!!!!

Yes, that problem is probably caused by race conditions. I also experienced race conditions while testing in qemu that did not show up in bochs or vmware. Qemus (as well as virtualbox') timing seems to be less deterministic than bochs' and vmware's timing. At least that is a good way to get rid of race conditions that are hard to find. (It's better than running the os many times on real pc while wondering why it crashes sometimes )

@piranha:
It just so happens that I checked out your source tree and built your kernel earlier today (I like to do this kind of thing when I'm bored...). If it helps any, I saw the same thing happen here. I guess that means that the problem is not computer-specific or emulator-specific. Probably a race condition like the Combuster and Korona said. I seem to remember experiencing this with my kernel when I was still using a lot of the code from JamesM's tutorials. After I re-wrote several parts myself (specifically the memory manager) and the problem went away.

Are there any common things that cause this?
Anyway to fix it?

-JL

Race condition usually occur when two threads try to access and manipulate one shared resource without proper synchronization. They can be caused by many reasons; the "easiest" way to get rid of them is to protect all structures with spinlocks or semaphores (or with cli -> manipulate -> sti on single processor machines). Pay attention to the order of the lock / unlock operations or your application will suffer from deadlocks.

I'm far from having multithreading and at the time when I had this problem, I didn't even have a PIT controller yet... (I was having problems with my IDT).
Weird...
Jules

Last time I had a race was when IRQ0 fired when I couldn't use it, so you don't really need two tasks to get one.
The PIT is usually still running if you haven't touched it...

But finding the cause of them is usually pretty tricky.