OSDev.org

Posted: **Sat Nov 24, 2007 7:28 pm**

Dont laugh, please... hehe

Just yesterday, I had two copies of my bootloader open in 2 different windows via explorer. I kept modifying the new copy, but assembling the old copy... ugh.

...And I wondered why it wasnt doing what I wanted.

Probably my worst mistake is crashing my video driver twice writing an OpenGL port for my engine. One of these times, it took Windows with it. (Of course, a reboot fixed both times.)

I cant think of any more yet, but I too make alot of silly mistakes--specially when its late and im tired

*sigh*

No body knows your code better than you do.. Unless it's 5 years later and ever you don't understand your own code!

I personally never had any trouble understanding my own code... Even code written 5years ago.

Then again, I always comment it, so thats probably why.

Posted: **Sat Nov 24, 2007 7:34 pm**

neon wrote: Just yesterday, I had two copies of my bootloader open in 2 different windows via explorer. I kept modifying the new copy, but assembling the old copy... ugh. ...And I wondered why it wasnt doing what I wanted.

Hehe, I do that all the time if I need to work without a real source control.

Posted: **Tue Nov 27, 2007 4:00 am**

lol I made one myself today. I couldn't find what the problem was for almost 5 minutes. I had a variable called "Cache" which was defined globally in Delphi like this:

Code: Select all

Cache           : Array [0..MAX_CACHED_LINES-1] of OneLineofText;

Then I wanted to set a pointer to this variable and find the last CR or LF in this buffer like this:

Code: Select all

(* ---------------------------------------- *)
procedure TForm1.Button2Click(Sender: TObject);
Var
  CurrentLine     : Array[0..MAX_STR-1] of Char;
  CurrentLinePtr  : PChar;
  CachePtr        : PChar;
begin
if (PChar(Integer(CachePtr) + (BytesRead-1))^ <> #13) and
   (PChar(Integer(CachePtr) + (BytesRead-1))^ <> #10) then
  begin
    Inc(CachePtr, BytesRead-1);
    While (CachePtr^ <> #13) and (CachePtr^ <> #10) do
      Dec(CachePtr);
  end;
CachePtr^ := #0;
CachePtr := @Cache;
ShowMessage(CachePtr);
end;
(* ---------------------------------------- *)

Well as you can see, I haven't set the "CachePtr" a pointer to the "Cache" variable. So "CachePtr" was pointing to an unknown memory location

Posted: **Fri Dec 07, 2007 9:36 am**

Well, heres a pretty good one:

I was just debugging my page frame allocation mechanism, because every time I added a new global class to my kernel, important data (such as the GDT) was overwritten. Anyone who has previously been bored of my posts in the past will know that I always say "get stable memory allocation working before anything else".

Anyway, I had written a remove_range(start, length) function to my physical memory allocator. The first thing the allocator does is remove known 'in-use' pages such as the BDA, kernel and so on from the bitmap of free pages. The problem? I had written:

Code: Select all

remove_range(kernelstart, kernelstart - kernelend);

For some odd reason, everything above the start address of the kernel was unavailable for allocation - hopefully, you can see why...

Cheers,
Adam

Posted: **Fri Dec 07, 2007 9:52 am**

he he he that's a cracker!

Posted: **Sat Dec 08, 2007 5:03 pm**

I tried putting new in the constructor of a global object in my C++ kernel. (It won't work because the constructor would have been called before my memory manager initialised.)

Posted: **Mon Dec 10, 2007 12:48 pm**

In a similar vein to AJ's...

Code: Select all

for (int i = USER_HEAP_START; i < USER_HEAP_INITIAL_SIZE; i += PAGE_SIZE)

should have been

Code: Select all

for (int i = USER_HEAP_START; i < USER_HEAP_INITIAL_SIZE+USER_HEAP_START; i += PAGE_SIZE)

Hooray for wraparound! It caused every page from 0xD000000 onwards to be allocated straight away which meant that when fork()ing every other process shared the same set of page tables, meaning my shared objects were being mapped into every address space instead of one!

Wow, that took me a long time to find... :S

Posted: **Fri Dec 14, 2007 8:04 am**

Okay I don't think this is a programming mistake more than it is a design problem but since it is related to programming I'll put it here. In the design of my file system's boot sector, I have a byte field just before the boot signature that is supposed to keep the checksum. I have written this explanation for this byte-long field:

SSFS Boot Sector's Documentation wrote:Boot Sectorâ€™s checksum. This value must be set to the sum of all the bytes in the boot sector (from Byte#0 to Byte#511 inclusive) without the carry bit to make it an 8-bits-long checksum. If this value is not equal to the sum of all 512 bytes of the boot sector, the boot sectorâ€™s code located at Byte#0 must detect this error and report it to the user.

Well the problem is that the check-sum byte is one of the bytes in the 512 byte range. So how I have to set this value, I still don't know

I am going to have to exclude Byte# 509 from the checksum

Posted: **Fri Dec 14, 2007 8:22 am**

Thats why most checksums aim for a sum of zero.

Add all other bytes, and calculate how much to need to add to the value to obtain 0x00. Set the checksum as *that value*. Then, any checking program just needs to ensure that the sum of all bytes in the header == 0.

Cheers,
Adam

Posted: **Fri Dec 14, 2007 8:45 am**

Wow you are right. *slaps himself in the head*. Thank you for pointing this out.

Posted: **Sat Dec 15, 2007 8:57 am**

Well I just considered your suggestion but the problem still exists. Suppose you have three bytes:

Byte#1 = 1
Byte#2 = 2
Byte#3 = 3

Now you have to calculate their checksum and write the result as Byte#2

The checksum will be 256 - (1+2+3) = 256 - 6 = 250

Now the byte order is:

Byte#1 = 1
Byte#2 = 250
Byte#3 = 3

Now if I calculate their sum, it will be 254, and not 0. That's the same problem I was having as before. The checksum field is one of the fields involved in calculating the checksum itself. So if it is changed later, then the checksum won't be correct. I fixed this problem with two solutions:

1) Completely exclude the checksum byte when calculating the checksum.
2) Set the checksum byte to zero initially.

Posted: **Mon Dec 17, 2007 1:56 am**

Setting the checkum byte to zero should suffice. If you add all the values adding a zero should not affect the end result.

Posted: **Mon Dec 17, 2007 3:07 am**

Back on topic:

I had in my code:

Code: Select all

SomeStruct *someStruct;

memcpy(... , ... , sizeof(someStruct));

sizeof(someStruct) would return the size of the pointer, not the size of the struct

.

Posted: **Mon Dec 17, 2007 3:46 am**

Code: Select all

...
XOR ah, ah
INT 16 ;Wait for a key press (Should be 16h, not 16)
CMP ah, 1Ch ;Enter pressed?
...

I write the code in the boot sector and boot my PC (not emulator) and get 'out of Horizontal/Vertical Frequency' message from the monitor. It took me about an hour to find the missing 'h'...

Other stupid thing I've done

I test protected mode without loaded IDT and create print_f proc. First instruction of the the proc is PUSHA, but I forget to add POPA instruction before RET, so CPU goes in triple fault

So from now I will test protected mode kernel in Virtual PC

Posted: **Wed Jan 02, 2008 2:23 pm**

I have to withdraw my previous entry and post a new one.

I spent ages wondering why I could never get my serial driver working. As it turns out I was casting the port number (for the outport) to a char. The only reason I never noticed before was because all the port numbers I had used fit within a char, unlike the serial ports.

OSDev.org

Dumbest mistake you have ever made