Your biggest OSdev /facepalm moment
- Firestryke31
- Member
- Posts: 550
- Joined: Sat Nov 29, 2008 1:07 pm
- Location: Throw a dart at central Texas
- Contact:
Your biggest OSdev /facepalm moment
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'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.
Owner of Fawkes Software.
Wierd Al wrote: You think your Commodore 64 is really neato,
What kind of chip you got in there, a Dorito?
- piranha
- Member
- Posts: 1391
- Joined: Thu Dec 21, 2006 7:42 pm
- Location: Unknown. Momentum is pretty certain, however.
- Contact:
Re: Your biggest OSdev /facepalm moment
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
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
SeaOS: Adding VT-x, networking, and ARM support
dbittman on IRC, @danielbittman on twitter
https://dbittman.github.io
dbittman on IRC, @danielbittman on twitter
https://dbittman.github.io
Re: Your biggest OSdev /facepalm moment
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.
When the chance of succeeding is 99%, there is still a 50% chance of that success happening.
- Combuster
- Member
- Posts: 9301
- Joined: Wed Oct 18, 2006 3:45 am
- Libera.chat IRC: [com]buster
- Location: On the balcony, where I can actually keep 1½m distance
- Contact:
Re: Your biggest OSdev /facepalm moment
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...
After compiling a 386 version of bochs it turned out I used JZ instead of JNZ around the code enabling SSE...
-
- Member
- Posts: 524
- Joined: Sun Nov 09, 2008 2:55 am
- Location: Pennsylvania, USA
Re: Your biggest OSdev /facepalm moment
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.
- AndrewAPrice
- Member
- Posts: 2299
- Joined: Mon Jun 05, 2006 11:00 pm
- Location: USA (and Australia)
Re: Your biggest OSdev /facepalm moment
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).
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:
Code: Select all
c0100d46 <_D4arch3x8613x86interrupts6EnableFZv>:
c0100d46: fb sti
c0100d47 <_D4arch3x8613x86interrupts7DisableFZv>:
c0100d47: fa cli
c0100d48 <isr0>:
c0100d48: fa cli
c0100d49: 6a 00 push $0x0
c0100d4b: 6a 00 push $0x0
The actual code in D is:
Code: Select all
public void Enable() {
asm {
naked;
"sti";
}}
public void Disable() {
asm {
naked;
"cli";
}}
The endless hours are stripping away all my code (I've just recently started porting my kernel to D btw).
My OS is Perception.
Re: Your biggest OSdev /facepalm moment
Using CX in pmode in loops, is a common fault, eg: you should always use
Not
Or you could end up with problems.
Code: Select all
mov ecx,10
Code: Select all
mov cx,10
- Love4Boobies
- Member
- Posts: 2111
- Joined: Fri Mar 07, 2008 5:36 pm
- Location: Bucharest, Romania
Re: Your biggest OSdev /facepalm moment
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.
"Computers in the future may weigh no more than 1.5 tons.", Popular Mechanics (1949)
[ Project UDI ]
[ Project UDI ]
- Firestryke31
- Member
- Posts: 550
- Joined: Sat Nov 29, 2008 1:07 pm
- Location: Throw a dart at central Texas
- Contact:
Re: Your biggest OSdev /facepalm moment
Not exactly a coding /facepalm moment, but...
Yeah, I somehow doubt that...
Yeah, I somehow doubt that...
Owner of Fawkes Software.
Wierd Al wrote: You think your Commodore 64 is really neato,
What kind of chip you got in there, a Dorito?
Re: Your biggest OSdev /facepalm moment
I disbelieve.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 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....
Every good solution is obvious once you've found it.
- Love4Boobies
- Member
- Posts: 2111
- Joined: Fri Mar 07, 2008 5:36 pm
- Location: Bucharest, Romania
Re: Your biggest OSdev /facepalm moment
Firestryke31 wrote:Not exactly a coding /facepalm moment, but...
Yeah, I somehow doubt that...
Hey, you guys are good.Solar wrote:I disbelieve.
"Computers in the future may weigh no more than 1.5 tons.", Popular Mechanics (1949)
[ Project UDI ]
[ Project UDI ]
Re: Your biggest OSdev /facepalm moment
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.
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.
OS for PowerPC Macs: https://github.com/narke/Einherjar
Operating system: colorForth computing environment for x86.: https://github.com/narke/Roentgenium
Operating system: colorForth computing environment for x86.: https://github.com/narke/Roentgenium
Re: Your biggest OSdev /facepalm moment
Classic one right here - amazingly this only showed up when I compiled with optimisations enabled:
Note the lack of initialisation. D'oh!!
Code: Select all
Symbol *pSym;
if (pSym->getBinding() == binding && pSym->getParent() == pParent)
- AndrewAPrice
- Member
- Posts: 2299
- Joined: Mon Jun 05, 2006 11:00 pm
- Location: USA (and Australia)
Re: Your biggest OSdev /facepalm moment
That in a way is good, because you end up ripping apart the source and fix 10 other bugs along the way.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.
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?).
My OS is Perception.
Re: Your biggest OSdev /facepalm moment
Switched from working on an assembly file, to working on a c++ file and wrote all the comments in asm style.
Working On:Bootloader, RWFS Image Program
Leviathan: http://leviathanv.googlecode.com
Kernel:Working on Design Doc
Leviathan: http://leviathanv.googlecode.com
Kernel:Working on Design Doc