Bochs getHostMem vetoed redirect

[Creature]

I was wondering what this actually means. I'm getting this error in my OS sometimes from Bochs (when I add new code that is not being executed). Everything works fine and sometimes when a new function or variable is added, I get this error and I don't really know what it means. Can anyone explain this to me and (if possible) how to prevent it from occurring or what's specifically wrong?

The full error line is:

Code: Select all

prefetch: getHostMemAddr vetoed direct read, pAddr=0x000af8c9

Thanks,
Creature

[Combuster]

you're executing IO space, in this case video memory. Now that's something you really should not try.

The real cause: check for stack overflows, out-of bounds fails, broken stackframes, double deletes and any of that sort untraceable stuff. Try an overdose caffeine

[Creature]

That all sounds logical, but the crash occurs after a function is added that is never called. I traced it to the paging code (where I switch to the first paging directory and actually enable paging). The paging code suddenly crashes but the weird thing is nothing in the code that's being run has changed. A function has been added and can be called, but it's never called, but it still messes everything up. This makes me think it is either something that's not in the source (such as a messed up linker script or something), something in the boot code, or something in the paging code. As far as I understand paging, my way of creating the directories and such should be correct (and it does work, until a function gets added...).

Code: Select all

void InitPaging()
{
        /* Physical memory size (GRUB detects this in kB, we use bytes). */
        FrameCount = GRUB_MEMORY_SIZE / PAGE_SIZE;
        Frames = (unsigned *) Alloc(GET_ID_FROM_BIT(FrameCount));
        memset(Frames, 0, GET_ID_FROM_BIT(FrameCount));

        /* Make a page directory. */
        KernelDir = (PageDirectory *) AllocAlign(sizeof(PageDirectory));
        memset(KernelDir, 0, sizeof(PageDirectory));
        KernelDir->Address = (unsigned) KernelDir->TablesPhys;

        /* Allocate 1024 page-tables for the page directory (do this now so the addresses can be identity mapped and frozen). */
        size_t PhysAddr;
        size_t i;

        for(i = 0; i < 1024; )
        {
                KernelDir->PageTables[i] = reinterpret_cast<PageTable *>(AllocAlignGetPhys(sizeof(PageTable), &PhysAddr));
                KernelDir->TablesPhys[i++] = PhysAddr | 0x7; /* The physical address with the 'Present', 'Read-Write' and 'UserMode' set. */
        }

        i = 0;

        /* Identity map. */
        while(i < CurAddress + PAGE_SIZE)
        {
                AllocateFrame(PAGE_GET(i, KernelDir), false, false);
                i += PAGE_SIZE;
        }

        /* Allocate frames for the heap's pages (now that everything is identity mapped). */
        for(i = HEAP_START; i < HEAP_START + HEAP_START_SIZE; i += PAGE_SIZE)
                AllocateFrame(PAGE_GET(i, KernelDir), false, false);

        /* Switch page directories and enable paging. */
        SwitchPageDir(KernelDir);

        /* Create the kernel heap. */
        KernelHeap = CreateHeap(HEAP_START, HEAP_START + HEAP_START_SIZE, 0xCFFFF000, false, false);

        /* Clone the kernel directory, so it can remain constant. Then switch to the cloned directory. */
        SwitchPageDir(ClonePageDir(KernelDir));
}

What makes it even more strange is the fact that not all functions crash and usually for some reason it's the code inside the function that crashes. If I comment the code out, it works suddenly, even if the functions is not being called or is still there. Usually it's the fact that I perform an operation on a variable of a vector-based class, which leads me to believe it's the heap, but the heap isn't even created yet, since the paging code magically crashes before the heap is even ever created.

Is there anything wrong with my paging code (that might lead to such crashes?). If anyone wants to check out other source files, the SVN source repository can be found here (click).

Thanks in advance,
Creature

[Firestryke31]

Are you sure you're mapping everything in properly? Are you keeping track of the stack? I find that these kinds of bugs can be caused by either a corrupt stack or incomplete loading (or improperly paged in code, the effect is similar).

[Combuster]

It always means that you are writing somewhere you should not.

You said the problem was caused by adding things. That means pieces in memory move, and other things get overwritten than they did before.

But as a good C programmer (you are developing an os) you should know that.

[Creature]

Arrrg... I found that, after a while of looking around. I had done this:

Code: Select all

for(i = 0; i < 1024; )
	{
		KernelDir->PageTables[i] = reinterpret_cast<PageTable *>(AllocAlignGetPhys(sizeof(PageTable), &PhysAddr));
		KernelDir->TablesPhys[i++] = PhysAddr | 0x7; /* The physical address with the 'Present', 'Read-Write' and 'UserMode' set. */
	}

and forgot to actually clear the tables as well.

Code: Select all

for(i = 0; i < 1024; )
	{
		KernelDir->PageTables[i] = reinterpret_cast<PageTable *>(AllocAlignGetPhys(sizeof(PageTable), &PhysAddr));
		memset(KernelDir->PageTables[i], 0, PAGE_SIZE);

		KernelDir->TablesPhys[i++] = PhysAddr | 0x7; /* The physical address with the 'Present', 'Read-Write' and 'UserMode' set. */
	}

Strange that this turns out to be a problem afterwards. Unless this is one of those things that magically fixes things for a while and then it breaks again after a while... (I'm hoping this fixes it all together ).

Thanks for your tips .