weird memory stuff #14

Closed
opened 2022-10-19 18:33:27 +00:00 by apio · 2 comments
Owner

There are issues with fork() and exec() and memory management.
At some point, they corrupt stuff, and a userspace pointer that is perfectly accessible in userspace is "not valid" in a system call, sometimes the kernel panics randomly... aka, moon is unstable right now.

Just putting this on the issue tracker so I don't forget it ^^

There are issues with fork() and exec() and memory management. At some point, they corrupt stuff, and a userspace pointer that is perfectly accessible in userspace is "not valid" in a system call, sometimes the kernel panics randomly... aka, moon is unstable right now. Just putting this on the issue tracker so I don't forget it ^^
Author
Owner

Ok, so this is a little bit clearer now. The userspace pointer is still perfectly valid, what happens is KernelHeap believes it's "full" and refuses to allocate space to map it into the kernel's address space. This is caused because something overwrites the data where KernelHeap's page bitmap is located, causing it to believe there are no free pages.

Ok, so this is a little bit clearer now. The userspace pointer is still perfectly valid, what happens is KernelHeap believes it's "full" and refuses to allocate space to map it into the kernel's address space. This is caused because something overwrites the data where KernelHeap's page bitmap is located, causing it to believe there are no free pages.
apio added the
bug
label 2022-10-22 08:29:43 +00:00
apio added the
wontfix
label 2022-10-31 08:58:09 +00:00
Author
Owner

Pretty much non-relevant now. We don't use KernelHeap to map userspace memory right now, so if we did try it it would probably fault. But right now it doesn't, so it's fine.

Except we use physical memory to access user stuff. So we have to stay in the kernel's address space + this will break on machines with more than 16GB of memory, since the bootloader only identity-maps the first 16GB of physical memory for us.

Pretty much non-relevant now. We don't use KernelHeap to map userspace memory right now, so if we did try it it would probably fault. But right now it doesn't, so it's fine. Except we use physical memory to access user stuff. So we have to stay in the kernel's address space + this will break on machines with more than 16GB of memory, since the bootloader only identity-maps the first 16GB of physical memory for us.
apio closed this issue 2022-10-31 09:00:23 +00:00
Sign in to join this conversation.
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: apio/Luna#14
No description provided.