OSDev.org

MSB4062 while compiling Thunder. Fixed it by running in the MSBuild Command Line. It took me a month to realise it.

It was my multitasking and virtual memory management code. It took about 3 months to get it working good.

I still have a bug, PIT (which supposed to switch tasks) stops firing after a couple times. My disable_irq() routine is not called, yet in bochs debugger I see IRQ0 masked in PIC after about 10 task switches. Doesn't matter how many task I start, it stops working at different task at different time. Very annoying, and I have no clue what's wrong. I don't think it's a race condition because in IRQ0's ISR I keep interrupt flag cleared all the time. I'm hunting this beast for months now.

bzt wrote:I still have a bug, PIT (which supposed to switch tasks) stops firing after a couple times. My disable_irq() routine is not called, yet in bochs debugger I see IRQ0 masked in PIC after about 10 task switches. Doesn't matter how many task I start, it stops working at different task at different time. Very annoying, and I have no clue what's wrong. I don't think it's a race condition because in IRQ0's ISR I keep interrupt flag cleared all the time. I'm hunting this beast for months now.

It's time to start commenting out code one line at a time until it starts working

I'd guess that some CPU state isn't being saved/restored properly. Something like EFLAGS, or FPU state...

Couple of them:
1. Tried to initialize a variable inside the header. 0xB8000 in this case, haven't had any output for days...
2. A broken keyboard translator, I was getting the right output but it was like this: h@e@l@l@o@@w@o@r@l@d@. What I did was remade the entire thing. Now it works like a charm.
3. IDT kept failing, everything was right except I forgot the alignment.
4. Physical memory bitmap: broken self written C++ library.

i had several bugs lying in my codes, some of them, years without noticing it. here is a few funny examples:

1. one of my 3d software randomly killed winamp. yes. this was in the xp times. i was not nulled a pointer, and it had garbage sometimes. it went into an api call, which later turned out to make funny things, like killing other programs, or bsoding.

2. i had an unknown bug just discovered something before releasing one of my games. i had a few hours to hunt it down, and fix it. i was not succesfull. i discovered that inserting char donotcrash[100000]; to a specific point of code fixes the segfault, and i released it like that. this was in the xp times.

3. i had several bugs turned out to be in the libraries/apis/operating systems i used

4. i once had an argument with somebody about how sucks the antivirus programs are. to illustrate this, i downloaded a few virus example and windows kernel privilige escalation samples (most of them was more than 5 years old). i compiled them, and checked with 20 different antivirus software. NONE of them detected the virus.exe file i compiled. we reported it to antivirus corporations, and from that point up to 5 years ALL of my programs was falsely detected as viruses

5. and to be more on-topic, dawn os had 20-30 very long-living bugs, mostly in the C compiler. but i hunted them down all.

---------

the newest long living bug was in the CHS tuple disk reading mechanism in the bootable dawn emulator.
when i had to read a new block, i returned memory garbage due to the array was adressed with 0x80*512 instead of 2*512 (i forgot to restore disk id).i had to hunt it for 3 days.

Couple of years ago I was solving bug in EXT2 driver for 3 weeks then I noticed documentation what I had was wrong.

SpyderT wrote:It's time to start commenting out code one line at a time until it starts working

I'd guess that some CPU state isn't being saved/restored properly. Something like EFLAGS, or FPU state...

Thanks for the suggestion!

I've already tried that. The CPU state (along with flags) are saved properly, and I don't use FPU at the moment. I've also tried commenting out portions of code (and used only dummy busy loops in threads), but the same. And interesting thing though, I've put a debug message in bochs when the IRQ0's mask changes in PIC, and it turned out it's constantly flip-flopping, even in a simple rep movsb cycle, without my irq_enable() / irq_disable() code being called.