OSDev.org

I find it difficult to believe that single-stepping showed ptr to have a non-null value but list->elements to be null after the assignment. Mind, I don't understand why the irrelevant variable ptr is used in the first place.

cyr1x wrote:I guess this bug does not occur when optimizations are disabled right?

I always develop with optimizations explicitly disabled. Once I'm done implementing and testing something with optimizations disabled, I re-enable them and test again.

iansjack wrote:I find it difficult to believe that single-stepping showed ptr to have a non-null value but list->elements to be null after the assignment. Mind, I don't understand why the irrelevant variable ptr is used in the first place.

ptr is just there to demonstrate that static_alloc is not returning NULL, yet list->elements is NULL. I haven't single-stepped it recently but I've definitely done it. I can't try again until I get my computer back though.

I also need to figure out why GDB says there are no debugging symbols in the debugging file I created, then shows debugging symbols for some of my functions but not all. The kernel is stripped, but before that, all the debugging symbols get objcopied to another file and a debug-link is added. It makes debugging very difficult, and that's why I haven't looked at it in the debugger recently.

Well, there doesn't seem to be much point in introducing a variable just to capture the value of the static_alloc and single-stepping as well. Watching the variable whilst single-stepping should be enough.

When you get a chance, try single-stepping again. If ptr has a non-null value and list->elements also has a non-null value after the assignment (which it really has to from what you have told us), then I would look at the kprintf function to see if it has a bug that is corrupting the stack. If the unbelievable has happened, and the assignment is somehow failing, then it's time to look at the generated assembler code.

Your printf is likely wrong. Your varargs passing might also be. If you make two nice fake pointers yourself, can you print them? Add attribute format printf to printk. Are you on a 64 bit system but printing pointers as 32 bit values?

Synon wrote:This bug:

I don't know how it's physically possible. How can list->elements be NULL when ptr is not? They are the same type, and there's no way any code is executing in between because interrupts are disabled and the interrupt/exception handler prints a message when it executes.

I'm so confused.

Is list initialized properly? not pointing to ROM?

sortie wrote:Your printf is likely wrong.

My print function used to print numbers in reverse. I only printed single digit numbers and other palindromes, so I never noticed it for a while until one day I was printing addresses and noticed they were all over the place.

Now I print into an array on the stack, the print the array backwards.

sortie wrote:Your printf is likely wrong. Your varargs passing might also be. If you make two nice fake pointers yourself, can you print them? Add attribute format printf to printk. Are you on a 64 bit system but printing pointers as 32 bit values?

That was my first thought, too. You could also try printing them with gdb.

Another option is that list points to some ROM that you didn't properly mark as reserved during initialisation. I've had something like this before and it was really confusing.

I was trying to test my new VGA driver, so I wrote a program to draw Mandelbrot set... then happened what happened...

iocoder wrote:I was trying to test my new VGA driver, so I wrote a program to draw Mandelbrot set... then happened what happened... [...]

Looks quite amazing, you should add animation and keep that as the wallpaper.

I don't have the source code or a suitable toolchain on my laptop but I can read the code on GitHub. b.zaar's question prompted me to take a look where the list is actually being allocated. The heap's blocklist is placement-allocated at 0xC0000000 (I'm following James M's tutorial on-and-off and that's where he placed his, so I did the same). Ofc at such an early stage my pages are only identity mapped and my emulator doesn't have 3 GiB RAM, so 0xC0000000 doesn't exist. I've also made the mistake of initialising my heap allocator before the page allocator, and the page allocator's initialisation function is what sets the page fault interrupt handler, hence why no error was being reported (when there's no specific interrupt handler set for an exception, the general handler just ignores it. Another thing to change). So, three things to fix. Sorry for wasting anybody's time.

My new chmod(1) turned out to be a bit buggy:

Got this while working on mouse support in my terminal driver... It's caused by mouse input being in the buffer before the terminal driver loads. I've not fully investigated it yet, but it's probably the code that copies the contents of the screen into the back-buffer being confused by the movement of the mouse cursor.

You've all got crazy OSes !!

Testing my ZeroOS desktop,, I tried to display a letter A in VESA mode 640x480x256 (top left corner) and all works ,except the top of the letter is distorted
I don't know how this happened, but I'm working on printing characters in VESA mode right now!

My harddisk driver broke when rewriting it: