Booting into Rust and deadlocking right away - a gnarly bug in my hobby kernel, one of many to come

[jannesan]

https://jannestimm.com/posts/first-gnarly-kernel-bug/

Hi everyone! I recently started on my OS dev journey and I had a first moment of frustration when trying to figure out a weird bug. Wrote a short post about that experience, hopefully it is at least mildly entertaining to some of you.

I just found out about this forum and I will be back for sure to ask for help and share more about my journey.

cheers, Jannes

[nullplan]

If I understand your blog post correctly, you are seeing a stack overflow. However, as per your linker script, you are allocating 64kB of stack space, and your kmain() (now kinit() in the repo) function only declares a small amount of local data. What is eating all that memory? 64kB ought to be enough for anyone! Is the FDT parser doing that? If so, maybe you need to call other functions during boot up, so it doesn't actually parse the whole FDT, but only the info you need at that point.

[jannesan]

Hi nullplan, thanks for your reply! Actually the commit I am talking about in the post has just 4kB of stack, here is the linker script: https://github.com/jannes/jannos/blob/9 ... 39/link.ld.

But indeed, it still seems weird that so much stack space is being used by the FDT parser. Looking at the Fdt::new function, it is not clear to me how it would result in even 1kB of stack usage. I guess I could dig deeper into this with gdb, but I was just happy to be able to continue implementation after figuring out a stack overflow caused the memory corruption.

Maybe I will eventually write the FDT parsing myself, I just felt overwhelmed looking at the devicetree spec and decided to skip getting into those details for now.