Telling dlmalloc() where the heap is

[srg]

Hi

I'm currently writing my memory manager and I have a curiuose problem with dlmalloc().

My kernel is loaded at 0xC0000000 and I want my Kernel heap to be at 0xE0000000.

I have written a page allocator, mapper and an sbrk and on their own they work really well.

If I try this:
*foo = malloc(0x100000); /* I want 1MB from the heap */

It calls my sbrk nicely and I can see using the bochs debugger that 1MB worth of pages (and their page table) have been mapped at 0xE0000000. Great!

But the trouble I'm having is that after this, I get a page fault that something (possibly dlmalloc) is writing to 0xC above that 1MB? huh?

So I get my mapper to map one more page than needed and the 0xC can then be written to.

But, now I get a page fault saying that something has try to write to the 0x802xxxxx region, way off my heap.

How can I tell dlmalloc where my heap is, or is there aome other problem

thanks
srg

[Brendan]

Hi,

But the trouble I'm having is that after this, I get a page fault that something (possibly dlmalloc) is writing to 0xC above that 1MB? huh?

Either some code uses memory that it didn't allocate, or dlmalloc is buggy.

What does your OS do to handle a page fault? You need some way of getting the EIP that is pushed on the stack when a page fault occurs. Use this EIP to find the code that caused the page fault and figure out why it caused the page fault.

So I get my mapper to map one more page than needed and the 0xC can then be written to.

You can't fix a bug by hiding it...

But, now I get a page fault saying that something has try to write to the 0x802xxxxx region, way off my heap.

Hmm - maybe there 2 bugs!


Cheers,

Brendan

[srg]

Hi,

But the trouble I'm having is that after this, I get a page fault that something (possibly dlmalloc) is writing to 0xC above that 1MB? huh?

Either some code uses memory that it didn't allocate, or dlmalloc is buggy.

What does your OS do to handle a page fault? You need some way of getting the EIP that is pushed on the stack when a page fault occurs. Use this EIP to find the code that caused the page fault and figure out why it caused the page fault.

So I get my mapper to map one more page than needed and the 0xC can then be written to.

You can't fix a bug by hiding it...

But, now I get a page fault saying that something has try to write to the 0x802xxxxx region, way off my heap.

Hmm - maybe there 2 bugs!


Cheers,

Brendan

Don't worry, I'm not tryng to hide it. Anyway, according to the 386 Programmers Manual, all that is on the stack is a small error code? I'll investigate.

I must admit I doubt dlmalloc is buggy, Tim and others use it. Also some linux's use it AFAIK.

srg

[Solar]

dlmalloc() has indeed been the base for the Linux memory management. The chance that you've found a bug in a release version of dlmalloc() is about as big as that it's a bug introduced by the GCC code generator.

[srg]

Right

Sorry about that Bendan, I've found out about where the EIP is saved.

Anyway, I do have a Page Fault handler that ATM pops into eax, ebx and ecx, writes 'P' to the first byte fo screen memory and then halts, so I can use the bochs debugger on it.

As for this problem, I've fixed a couple of bugs of my own and it never tries to write anything in the 0x802xxxxx range any more.

BUT There is still an overshoot above tha amount of memory requested to be allocated, and it's by 12 bytes. I've tracked down the address of the offending instruction and it's in dlmalloc. What's more, the more times I call malloc, the overshoot (for want of a better word ) gets bigger and bigger.

Could I have my dlmalloc mal-adjusted possibly?

I have it attached.

srg

[srg]

D'oooooooooohhhhhhhhhhhh

It was an off by one error in my page mapping loop, I forgot that pages start a 0 and not one :-[

thanks for the help
srg