Custom oom handler that calls panic instead of abort #7
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Currently, the
Heap
andLockedHeap
uses the defaultoom
handler, which callsintrinsics::abort()
. On thex86_64
architecture, this generates aud2
instruction, generating an invalid opcode exception.While using this library in a kernel, allocating too much memory will call the default oom handler and generate an
INVALID OPCODE
exception that points to the firstud2
instruction inalloc::oom
(0x1073fc
in my case):I find the exception message unhelpful. So instead of generating an exception, we can set a custom
oom
handler by implementingoom
forHeap
andLockedHeap
. Customoom
handlers will be important later when we want to gracefully handle errors. My PR results in the following message when we run out of memory.Testing
You can test this PR by adding the following to
src/lib.rs
ofblog_os