You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've been studying the elf loading procedure for SOS processes defined in elf.c. I think I've stumbled upon a bug: if the mapping fails, the frame cap is deleted and the slot is freed (the frame is also freed but is still mapped in SOS) however the code continues to use these afterwards which I expect to result in an exception around here where an attempt is made to use the frame cap.
The comment is a bit mysterious -- when it mentions all frames being mapped in, I assume it is talking about the SOS address space, but why "continue on to do the write" on a frame that's not mapped into the process' address space?
The text was updated successfully, but these errors were encountered:
I've been studying the elf loading procedure for SOS processes defined in elf.c. I think I've stumbled upon a bug: if the mapping fails, the frame cap is deleted and the slot is freed (the frame is also freed but is still mapped in SOS) however the code continues to use these afterwards which I expect to result in an exception around here where an attempt is made to use the frame cap.
The comment is a bit mysterious -- when it mentions all frames being mapped in, I assume it is talking about the SOS address space, but why "continue on to do the write" on a frame that's not mapped into the process' address space?
The text was updated successfully, but these errors were encountered: