OSDev.org

What has been your biggest /facepalm moment in OS development so far? Post it here for a laugh, and let others learn from your mistakes!

I'll start off with two, the first of which I found when I was trying to fix the second:

I was trying to implement some kind of sysCall API using an interrupt. It was really simple, just pass the sysCall number in eax and a pointer to the parameters in ebx and do an INT 0x30. I had the stubs, the ISR for the interrupt, everything, but every time I tried to do a putStr syscall, it crashed and reset. I couldn't figure out why it wouldn't work, and was putting debug output everywhere. Finally, I looked through the interrupt initialization function, and saw I never registered the ISR function with the stub. It would call whatever was in that slot, which was undefined, and execute random code, and die.

The second one was in my memory management, where I was trying to split my heap block to malloc some memory out. It compares the new block address plus it's length to the old block's next address to see if we have enough memory to allocate. Unfortunately, I use the value '0' to indicate the end of the linked list, which (in theory) is always less than the new block's address + length, and so the comparison would fail, and so the block split would fail, and so the malloc would fail, and so the free would fail, and so everything was epic fail because I didn't check to see if we were splitting the last block.

I added a signal handling loop to my scheduler, and it wouldn't work.

I figured out that I had written
while(task->next != 0) {...;task=task->next;};
When it should've been
while(task != 0) {...;task=task->next;};

It didn't work cause I used only 2 tasks (0 and 1) and when it tried to ind signals, it only found them for 0, not 1 (and my testing had 1 receiving the signals).

-JL

As I was coding the GDT and it wouldn't work at all, it turned out that I had used a word for one variable instead of a byte which made everything fail. I had been searching that error for 3 days.

Those cases when I modified the CR4 feature enabling code and my OS stopped working on older computers.

After compiling a 386 version of bochs it turned out I used JZ instead of JNZ around the code enabling SSE...

I spent 2 days debugging my SMP code because it kept on putting my BSP into a halt state and not doing anything to the APs. Eventually I found that I had used 'i = 0' instead of 'i = 1' in the for loop that starts processors, and it was trying to start my BSP as if it was an AP.

I was wondering why every time I enabled interrupts, interrupt 0 (divide by zero) would fire. I've stripped apart my GDT, IDT, and Interrupt code OVER AND OVER AGAIN!!! I was thinking maybe somehow I mapped IRQ0 to be Interrupt 0.

I've had all sorts of errors, like iret'ing and running out of stack space, and mysterious "CS equals 0" errors.

I've diassembled and stepped botchs through my code a lot. Then eventually I finally saw it in the disassembled code:
See the code where I enable/disable interrupts? There is no return! When I called the function to enable interrupts, the code simply fell through to isr0 and then tried iret'ing.

The actual code in D is: I over-missed the fact that "naked" means the compiler will not insert ANY code automatically (not even a simple prologue containing "ret" in the prologue).

The endless hours are stripping away all my code (I've just recently started porting my kernel to D btw).

Using CX in pmode in loops, is a common fault, eg: you should always use Not Or you could end up with problems.

The biggest /facepalm moment was when I coded half a day to implement some functionality for my OS and realised I forgot to turn the computer on so I didn't actually do anything And that still doesn't top this.

Not exactly a coding /facepalm moment, but...
Yeah, I somehow doubt that...

Love4Boobies wrote:...I coded half a day to implement some functionality for my OS and realised I forgot to turn the computer on so I didn't actually do anything

I disbelieve.

I wasted half a day once hunting a bug that seemed impervious to whatever I did to trace it down. No matter where I put the debug output in the source, it didn't show up when the kernel ran.

Turned out I had reorganized my Makefile, including a new name for the kernel image, but forgot to tell bochs to use that new name (it was loading the same old image over and over again). /facepalm....

Firestryke31 wrote:Not exactly a coding /facepalm moment, but...
Yeah, I somehow doubt that...

Solar wrote:I disbelieve.

Hey, you guys are good.

Some days ago I started again to code my operating system (I will show you later: 1,2 months).
I tried to set up GDT and IDT but it was not working.
I spent 11 hours of no-stop bug hunting to figure out that I used "unsigned short int" (16 bits) instead of "unsigned int" (32 bits) for one of the structure member.
After that I corrected that everything worked as expected.

Classic one right here - amazingly this only showed up when I compiled with optimisations enabled:
Note the lack of initialisation. D'oh!!

narke wrote:Some days ago I started again to code my operating system (I will show you later: 1,2 months).
I tried to set up GDT and IDT but it was not working.
I spent 11 hours of no-stop bug hunting to figure out that I used "unsigned short int" (16 bits) instead of "unsigned int" (32 bits) for one of the structure member.
After that I corrected that everything worked as expected.

That in a way is good, because you end up ripping apart the source and fix 10 other bugs along the way.

Sometimes I will type a lot of code before testing, and magically it will just work as expected, then a while later something will break and I'll come back and see the original code I wrote and noticed it was full of bugs and I wonder how it ever worked the first time (e.g. I'm writing to physical addresses not the virtual address of a page table - how could that work when the VM only has 32mb of memory while my kernel is at 3GB?).

Switched from working on an assembly file, to working on a c++ file and wrote all the comments in asm style.