OSDev.org

So I was trying to allocate memory using my 'kmalloc' function and I am receiving Page Faults. This problem happens whenever I allocate more that roughly 500KB. I have tried changing the amount of physical memory QEMU has/my memory manager has with no change.

I am probably missing something and I'm sorry for not being the best at this. If you need me to post code I will do or you can look in my git-hub https://github.com/teenHack42/MatrixOS. my paging code is under 'src/arch/x86/paging.c'

Thanks in advance.

Hi,

I spent about 10 minutes looking at your code. Here are my quick impressions:

You seem to have taken a lot from the James Molloy tutorial (at least the heap part). This code is riddled with bugs. Please see this wiki. There are several heap related bugs that you have not yet removed.

I also looked for where you call Create_Heap(). I did not find it in the short time I was willing to look. However, I would consider how you are calculating the memory limits and review that logic as well. I suspect you will have an issue with expand().

Finally, what EIP and/or address is causing the fault? Review your link map to determine the function and start narrowing the lines down.

eryjus wrote: Finally, what EIP and/or address is causing the fault? Review your link map to determine the function and start narrowing the lines down.

I disassembled my code and found that at the EIP:1036a3 these instructions occur: This is in my 'alloc' function and is something to do with moving my magic number (123890ab).
I am guessing that I need to do what the wiki says and rewrite my heap.

Thankyou. any more help appreciated.

teenHack42 wrote:I disassembled my code and found that at the EIP:1036a3 these instructions occur:

Code: Select all

1036a3:	c7 00 ab 90 38 12    	movl   $0x123890ab,(%eax)

This is in my 'alloc' function and is something to do with moving my magic number (123890ab).

That's good. Now you need a little context for the disassembled line. Obviously, the address in %eax is bad (causing a page fault when you try to write data to that memory location). This could be in a header or footer. It is most likely in a portion of your alloc() function that does not get exercised very often (or you would have found it earlier). Since you are writing in C and debugging in assembly, you should get used to the relationships. Look at a bigger picture than just a single line of code and see if you can identify what line in the C function this is happening in. This might even give you enough information to find the error.

Also, get a copy of Bochs with its internal debugger. Use the debugger to dump the register contents when you get the error. You can use the Bochs Magic Breakpoint to break at the top of the block of code (i.e. just after an if statement) where the line of code in error was.

Finally, when you finally get to the point you are implementing your own heap, identify your assumptions and validate them thoroughly in code. With a header and footer organized like this, there are a number of things you can and should verify which are not being done in the JMolloy code. Keep in mind that your kernel's Heap Manager will allocate and deallocate blocks of heap memory, but has no control that is done with that memory once it has been allocated (and the block limits could easily have been overrun). It is possible that you could introduce an inconsistency into your linked list that causes issues quite a ways down the road. In my 32-bit kernel, I wrote a ValidateHeapHdr() function to look at all these different things that could go wrong and panic the kernel if a check didn't pass. Then I called my validation function on entry, on exit, and nearly every place I made a change to the structures.

teenHack42 wrote:I am guessing that I need to do what the wiki says and rewrite my heap.

Don't let that discourage you; you will be much happier with it anyway, since it will be your code. Plus you will have the benefit of knowing what you wanted to do and why you wanted to do it (compared to copy-pasting code you don't fully understand).