OSDev.org

The Place to Start for Operating System Developers
It is currently Thu Mar 28, 2024 3:33 am

All times are UTC - 6 hours




Post new topic Reply to topic  [ 10 posts ] 
Author Message
 Post subject: Crash when writing to address in allocated memory
PostPosted: Mon Nov 06, 2017 4:32 am 
Offline
Member
Member

Joined: Mon May 15, 2017 11:04 am
Posts: 50
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 :mrgreen: ). 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.
Attachment:
MMIO_Reg_1108EF.PNG
MMIO_Reg_1108EF.PNG [ 14.65 KiB | Viewed 11417 times ]


Top
 Profile  
 
 Post subject: Re: Crash when writing to address in allocated memory
PostPosted: Mon Nov 06, 2017 5:01 am 
Offline
Member
Member
User avatar

Joined: Sat Mar 31, 2012 3:07 am
Posts: 4591
Location: Chichester, UK
What physical address have you mapped that memory page to?


Top
 Profile  
 
 Post subject: Re: Crash when writing to address in allocated memory
PostPosted: Mon Nov 06, 2017 12:48 pm 
Offline
Member
Member

Joined: Mon May 15, 2017 11:04 am
Posts: 50
iansjack wrote:
What physical address have you mapped that memory page to?

0x1108EB is the physical address


Top
 Profile  
 
 Post subject: Re: Crash when writing to address in allocated memory
PostPosted: Mon Nov 06, 2017 1:00 pm 
Offline
Member
Member
User avatar

Joined: Sat Mar 31, 2012 3:07 am
Posts: 4591
Location: Chichester, UK
That's just normal, usable RAM (assuming your mapping is correct). Your problem lies elsewhere.


Top
 Profile  
 
 Post subject: Re: Crash when writing to address in allocated memory
PostPosted: Mon Nov 06, 2017 1:20 pm 
Offline
Member
Member

Joined: Mon May 15, 2017 11:04 am
Posts: 50
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.


Top
 Profile  
 
 Post subject: Re: Crash when writing to address in allocated memory
PostPosted: Mon Nov 06, 2017 2:34 pm 
Offline
Member
Member
User avatar

Joined: Sat Mar 31, 2012 3:07 am
Posts: 4591
Location: Chichester, UK
"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.


Top
 Profile  
 
 Post subject: Re: Crash when writing to address in allocated memory
PostPosted: Mon Nov 06, 2017 3:55 pm 
Offline
Member
Member

Joined: Mon May 15, 2017 11:04 am
Posts: 50
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:
Attachment:
GP_WriteTest.PNG
GP_WriteTest.PNG [ 12.53 KiB | Viewed 11322 times ]


Top
 Profile  
 
 Post subject: Re: Crash when writing to address in allocated memory
PostPosted: Mon Nov 06, 2017 6:13 pm 
Offline
Member
Member

Joined: Fri Aug 26, 2016 1:41 pm
Posts: 671
You could always post your code to Github or some other service so that we can look at it.


Top
 Profile  
 
 Post subject: Re: Crash when writing to address in allocated memory
PostPosted: Tue Nov 07, 2017 12:47 am 
Offline
Member
Member
User avatar

Joined: Sat Mar 31, 2012 3:07 am
Posts: 4591
Location: Chichester, UK
Perhaps you are overwriting your paging tables or your GDT. This is the sort of information that a debugger will tell you.


Top
 Profile  
 
 Post subject: Re: Crash when writing to address in allocated memory
PostPosted: Tue Nov 07, 2017 3:16 am 
Offline
Member
Member

Joined: Mon May 15, 2017 11:04 am
Posts: 50
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:
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:
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:
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;
}


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 10 posts ] 

All times are UTC - 6 hours


Who is online

Users browsing this forum: Google [Bot] and 65 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group