sbrktest - program for testing sbrk
/testbin/sbrktest [test-number ...]
sbrktest contains a number of tests for memory allocation, using the sbrk low-level interface directly instead of via malloc. It is similar to malloctest in general layout and approach, but concentrates on kernel-level memory allocation rather than the behavior of C malloc.
There are 21 tests:
|1||Allocate one page.|
|2||Allocate and free one page.|
|3||Allocate and free several pages.|
|4||Allocate several pages and free them one at a time.|
|5||Check the heap end. This test crashes intentionally.|
|6||Allocate and check the heap end. This test crashes intentionally.|
|7||Allocate and free and check the heap end. This test crashes intentionally.|
|8||Allocate several, free some, then check the heap end. This test crashes intentionally.|
|9||Allocate all memory in a big chunk.|
|10||Allocate all memory one page at a time.|
|11||Allocate a lot and intentionally leak it.|
|12||Fork and then allocate.|
|13||Allocate and then fork.|
|14||Allocate and then fork and free.|
|15||Allocate, fork, allocate more, and free.|
|16||Small stress test.|
|17||Randomized small stress test.|
|18||Small stress test with specific seed.|
|19||Large stress test.|
|20||Randomized large stress test.|
|21||Large stress test with specific seed.|
One or more tests may be run specifically by giving the numbers on the command line; otherwise, sbrktest prints the list and prompts for a test number to run.
Note that the tests that crash intentionally should crash the sbrktest program with an illegal memory access ( SIGSEGV) -- they should not crash your kernel.
The tests that attempt to allocate all available memory may be slow, depending on the per-process limits you place on memory allocation (if any) relative to the amount of available physical RAM.
sbrktest uses the following system calls:
sbrktest should work properly once you have implemented the sbrk system call and a virtual memory system that supports dynamic memory allocation. It will not work with dumbvm.