OSDev.org

The Place to Start for Operating System Developers
It is currently Mon Oct 26, 2020 8:01 am

All times are UTC - 6 hours




Post new topic Reply to topic  [ 3 posts ] 
Author Message
 Post subject: Debugging via COM1 port makes strange behavior of kernel
PostPosted: Wed Oct 02, 2019 12:45 pm 
Offline

Joined: Thu Mar 14, 2019 1:45 pm
Posts: 8
Hello!

About a week ago I tried to debug my kernel through COM1 serial port. I used tutorial on the wiki and it works. But now I tried to upgrade the way of debugging, by recreating debugging function.
These two functions are my currently work:

Code:
// Help function for DebugWrite, givs int args in every %x position:
void vDebugWrite(const char *x, va_list args)
{
   for(int i = 0; x[i] != '\0'; i++)
   {
      if((x[i] == '%') && (x[i + 1] == 'x'))
      {
         int Value = va_arg(args, int);

         char Holder[] = {};
         
         kitoa(Value, Holder, 16);

         for(int a = 0; Holder[a] != '\0'; a++)
         {
            write_serial(Holder[a]);
         }
         
         // It's here!
         //int *pom = &Holder;
         //kprintf("Holder address: 0x%x\n", pom);
         i++;
      }
      else write_serial(x[i]);
   }
}

// Write string to port:
void DebugWrite(const char *x, ...)
{
   va_list args;
   va_start(args, x);
   
   vDebugWrite(x, args);
   
   va_end(args);
}


These functions are working similar to ANSI C printf function. But here is the bug. The code that I tagged "It's here!", these next two lines, makes functions works perfectly, but when this code is commented, problems are encountered.

Here is how debug file looks like without these to lines:
Quote:
Strayex Kernel Debug Mode
Using serial port COM1
Full kernel name: Strayex Kernel v1.0.1 Alpha
Adress of p: 0x11f4 <- it's here!


Address of var "p", created statically in kernel is 0x11f458 in debugging in QEMU nad VirtualBox. Because my kprintf() function is working properly, I can read it from screen. But I don't know why these two extra lines of code, that I don't want to display on screen this data, makes code working. Correct address is on screen and in logfile.

Please help, I don't see problem here, maybe it's some value passing into stream of serial port. I really don't know. If it is necessary, I will paste here kprintf() function code.
And, of corse, thank you for your answers! :)

_________________
My GitHub: https://github.com/StraykerPL


Top
 Profile  
 
 Post subject: Re: Debugging via COM1 port makes strange behavior of kernel
PostPosted: Wed Oct 02, 2019 1:33 pm 
Offline
Member
Member
User avatar

Joined: Fri Oct 03, 2008 4:13 am
Posts: 142
Location: Ogre, Latvia, EU
The cause of the problem is your 'Holder' variable. You create it as zero-sized array, which is located on stack.

Let me guess, your kitoa() function writes something into this array. But this is C. It does not magically re-allocate memory to make the array bigger. It also does not check that it is writing to memory outside of the array. It trusts that you know what you're doing and writes the data where it was told to.

But since you're writing past the end of the (0-sized) array, you're overwriting memory that might be used for other purposes. But once you're start doing that, you can expect all kinds of strangeness.

If you can predict how many bytes at most the Holder will occupy, just declare it to be that size.

Code:
// should be enough to hex-format an 32-bit integer + add \0.
char Holder[9];

_________________
If something looks overcomplicated, most likely it is.


Top
 Profile  
 
 Post subject: Re: Debugging via COM1 port makes strange behavior of kernel
PostPosted: Wed Oct 02, 2019 1:44 pm 
Offline

Joined: Thu Mar 14, 2019 1:45 pm
Posts: 8
Velko wrote:
The cause of the problem is your 'Holder' variable. You create it as zero-sized array, which is located on stack.

Let me guess, your kitoa() function writes something into this array. But this is C. It does not magically re-allocate memory to make the array bigger. It also does not check that it is writing to memory outside of the array. It trusts that you know what you're doing and writes the data where it was told to.

But since you're writing past the end of the (0-sized) array, you're overwriting memory that might be used for other purposes. But once you're start doing that, you can expect all kinds of strangeness.

If you can predict how many bytes at most the Holder will occupy, just declare it to be that size.

Code:
// should be enough to hex-format an 32-bit integer + add \0.
char Holder[9];


That is it! Works perfectly! Thank you very much! :D

_________________
My GitHub: https://github.com/StraykerPL


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

All times are UTC - 6 hours


Who is online

Users browsing this forum: Google [Bot] and 17 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