OSDev.org

Posted: **Wed Oct 02, 2019 12:45 pm**

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: Select all

// 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:

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!

Posted: **Wed Oct 02, 2019 1:33 pm**

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: Select all

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

Posted: **Wed Oct 02, 2019 1:44 pm**

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: Select all
// should be enough to hex-format an 32-bit integer + add \0.
char Holder[9];

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

OSDev.org

Debugging via COM1 port makes strange behavior of kernel

Debugging via COM1 port makes strange behavior of kernel

Re: Debugging via COM1 port makes strange behavior of kernel

Re: Debugging via COM1 port makes strange behavior of kernel