Currently, the Heap and LockedHeap uses the default oom handler, which calls intrinsics::abort(). On the x86_64 architecture, this generates a ud2 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 first ud2 instruction in alloc::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 implementing oom for Heap and LockedHeap. Custom oom 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.
PANIC in /path/to/linked-list-allocator/src/lib.rs at line 180:
Out of memory
Testing
You can test this PR by adding the following to src/lib.rs of blog_os
let mut stack: alloc::Vec<usize> = vec![0; 100_000_000];
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