OSDev.org

Posted: **Mon Nov 06, 2017 4:32 am**

Hi!

I'm currently writing a heap manager and testing it using C++ strings.
My problem is that my OS crashes when i try to write to the address 0xFFFFFF00001108EB.
Since I have a functional IDT and ISR (most ISRs are currently halting the processor) and since there are some weird symbols at that address, this seems to be a system relevant memory address (MMIO register or something). The question is can i detect where it comes from? And where are informations about MMIO registers stored?
The following is a screenshot of my OS. I'm adding text to the string and therefore allocating space (the text is german

). The first address is the address of my _end symbol, the second address is the address of the last char that you can see in the line below. When i try to add another "-" to the last string and therefore overwriting this wired 3-"-"-symbol, the OS crashes.

Posted: **Mon Nov 06, 2017 5:01 am**

What physical address have you mapped that memory page to?

Posted: **Mon Nov 06, 2017 12:48 pm**

iansjack wrote:What physical address have you mapped that memory page to?

0x1108EB is the physical address

Posted: **Mon Nov 06, 2017 1:00 pm**

That's just normal, usable RAM (assuming your mapping is correct). Your problem lies elsewhere.

Posted: **Mon Nov 06, 2017 1:20 pm**

iansjack wrote:That's just normal, usable RAM (assuming your mapping is correct). Your problem lies elsewhere.

Well what else can crash an OS without throwing an interrupt?
There seem to be multiple 64-Bit entries in that area, but only when overwriting 0x1108EB it crashes.

Posted: **Mon Nov 06, 2017 2:34 pm**

"Crash" is rather a vague term. I suspect that you are triple-faulting, and there could be a number of reasons for this. Just writing to a properly mapped location in physical RAM will not cause a triple-fault (or any kind of exception), Invalid stacks often cause triple-faults as they prevent interrupt/exception handlers from running.

Your best bet is to single-step your code in a debugger.

Posted: **Mon Nov 06, 2017 3:55 pm**

iansjack wrote:"Crash" is rather a vague term. I suspect that you are triple-faulting, and there could be a number of reasons for this. Just writing to a properly mapped location in physical RAM will not cause a triple-fault (or any kind of exception), Invalid stacks often cause triple-faults as they prevent interrupt/exception handlers from running.

Your best bet is to single-step your code in a debugger.

I set the whole heap memory to zero, so there shouldn't even be anything or at least i should get a triple fault when setting the memory...
My OS has a working (interrupt) keyboard driver that outputs to the display and if i don't override 0x1108EB, i can write to the display. Therefore, the stack can't be invalid and interrupts work.
Is it maybe not a good idea to put the heap directly at the end of the kernel?

EDIT:
I've added some things to the kernel. Now &_end is 0x1134E0 and the "triple fault address" is 0x11370B, but this time i'm only getting a general protection fault.

EDIT2:
This is a really weird bug... I had enough time to write some text before the GP-fault (with code 0) occured:

Posted: **Mon Nov 06, 2017 6:13 pm**

You could always post your code to Github or some other service so that we can look at it.

Posted: **Tue Nov 07, 2017 12:47 am**

Perhaps you are overwriting your paging tables or your GDT. This is the sort of information that a debugger will tell you.

Posted: **Tue Nov 07, 2017 3:16 am**

My GDT and paging tables are both statically allocated variables/stucts/arrays and therefore have to be in kernel address space (so below &_end).

My Project is online on GitHub:
https://github.com/DevNoteHQ/MOS
The kernel source code is in /system/kernel/src/
GS register is set in cpu/cpu.cpp (the GS register contains a pointer to struct CPU::CPU BSP which contains the address of the GDT).
GDT is configured in init/gdt.cpp
Paging is first configured in init/boot.asm and then redone in mm/vmm/init.cpp (i should maybe change that).
Note that i am using 1GB pages for mapping the kernel.
init/boot.asm starts System::Init() in init/init.cpp which starts all the other things.
Also note that i am standard including some header files. These files can be found in /include/ (libMOS.a is not in working right now and therefore not used).

Thank you for your help!

EDIT4:
So in a long mode kernel to debug with VMware Player, you have to connect as 32-bit debugger (port 8832), set a breakpoint at your trampoline code (where you are in long mode but still use 32-bit addresses), continue, disconnect and connect as 64-bit debugger (port 8864).
Can someone maybe tell me why nasm doesn't create debug symbols? I used:

Code: Select all

NASFLAGS = -f elf64 -F dwarf -g
$(OBJDIR)/%_asm.o : $(SRCDIR)/%.asm
	$(mk) $(@D)
	$(ASM) $(NASFLAGS) $< -o $@

And -gdwarf for gcc.

EDIT5:
I fixed the issue. I'm not sure what the cause was, but after redoing my string class the issue was gone. It's possible that the string methods tried to free memory that didn't exist and that if(addr == NULL) return; didn't work in my free()-function.

Could someone more experienced in C++ take a quick look at my string class?

string.hpp:

Code: Select all

class string
{
private:
	char* cstr;
public:
	string();
	string(const char* str);
	string(const string& str);
	~string();

	operator char*();
	operator const char*();
	string& operator+=(const string& rhs);
	string& operator=(const string& rhs);
	friend string operator+(const string& lhs, const string& rhs);
	friend string operator+(const string& lhs, char rhs);
	friend string operator+(const string& lhs, const char* rhs);
	friend string operator+(char lhs, const string& rhs);
	friend string operator+(const char* lhs, const string& rhs);
};

string.cpp:

Code: Select all

string::string()
{
	cstr = 0;
}

string::string(const char *str)
{
	cstr = new char[strlen(str) + 1];
	strcpy(cstr, str);
}

string::string(const string& q)
{
	cstr = new char[strlen(q.cstr) + 1];
	strcpy(cstr, q.cstr);
}

string::~string()
{
	if (cstr)
		delete[] cstr;
}

string::operator char*()
{
	return cstr;
}

string::operator const char* ()
{
	return cstr;
}

string& string::operator= (const string& rhs)
{
	if (this == &rhs) return *this;

	if (cstr)
		delete[] cstr;
	cstr = new char[strlen(rhs.cstr) + 1];
	strcpy(cstr, rhs.cstr);
	return *this;
}

string& string::operator+= (const string& rhs)
{
	uint32_t size = strlen(cstr) + strlen(rhs.cstr) + 1;
	char *tmp = new char[size];
	strcpy(tmp, cstr);
	strcat(tmp, rhs.cstr);
	delete[] cstr;
	cstr = tmp;
	return *this;
}

string operator+ (const string& lhs, const string& rhs)
{
	return string(lhs) += rhs;
}

string operator+ (const string& lhs, char rhs)
{
	return string(lhs) += string(rhs);
}

string operator+ (const string& lhs, const char* rhs)
{
	return string(lhs) += string(rhs);
}

string operator+ (char lhs, const string& rhs)
{
	return string(lhs) += rhs;
}

string operator+ (const char* lhs, const string& rhs)
{
	return string(lhs) += rhs;
}

OSDev.org

Crash when writing to address in allocated memory

Crash when writing to address in allocated memory

Re: Crash when writing to address in allocated memory

Re: Crash when writing to address in allocated memory

Re: Crash when writing to address in allocated memory

Re: Crash when writing to address in allocated memory

Re: Crash when writing to address in allocated memory

Re: Crash when writing to address in allocated memory

Re: Crash when writing to address in allocated memory

Re: Crash when writing to address in allocated memory

Re: Crash when writing to address in allocated memory